scrumの紹介とxpプロジェクトへの適用(scrum and xp)

35
Scrum のののの XP のののののののののの 2002/06/21 Masashi Umezawa のののの XP ののののの

Upload: masashi-umezawa

Post on 13-Apr-2017

946 views

Category:

Software


0 download

TRANSCRIPT

Page 1: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

Scrumの紹介とXPプロジェクトへの適用

2002/06/21Masashi Umezawa

豆ナイト XP スペシャル

Page 2: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

はじめに開発手法はたくさん覚えれば良いというものではない 開発手法を実際に使って感触を得ることのほうが大

事だからといって一つの開発手法に固執するのも良くない 無意識に視野を狭くしている

他の手法に学ぶべきことは多いかもしれない どんなものにも得手不得手はある

Case by case で使い分ける プロジェクトごとにプロセスを作り上げる

Page 3: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

Scrumに注目している理由XP プロジェクトを 3 回ほど経験してきたが… 限界を感じている

全体的視点の欠如 「メタファ」が思い浮かばない ビックリファクタリングへの恐怖

規模と期間 4 人程度が限界 3 ヶ月程度で燃え尽きる

オンサイト顧客 きわめて有効だが、現実的には実施が困難

コーチやマネージャへの負担 プラクティスが弱い 属人的

Page 4: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

Scrumのなりたち

実は XP よりも古い Jeff Sutherland (Easel   Corporation)

Smalltalker Enfin Smalltalk

Ken Schwaber (Advanced Development Methods) プロセス屋さん 1994 年ごろから Jeff と協力

Mike Beedle (e-Architects) 6 年以上にわたって Scrum を実践 XP との融合

Page 5: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

カオスをコントロールする(1)

Ken Schwaber “Controlled Chaos: Living on the Edge”, Cutter IT Journal, 1996

長年きちんとしたプロセスを定義しようとしてきたが、うまくいかない結局のところソフトウェア開発は、一種のカオス 特定の入力に対して、一定の出力が定まらない 正確に繰り返し可能なほどにプロセスを詳細化しきれない そもそも高度に知的で創造的なもの

「定義された」プロセスでコントロールできるものではない

Page 6: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

カオスをコントロールする(2)

製造業の世界でも、きちんと定義できないプロセスに関しては、全く異なる管理の仕方が使われている 例 : シリコン被膜形成など

「定義済み」プロセスに対する「経験的」プロセス Process Dynamics, Modeling and Control, Babatunde A. Ogunnaike, et al

状態を常にモニタリングする フィードバックを受けてこまめな調整を行う

ラグビーのスクラムのごとく、柔軟に姿を随時変えて、ゴールにたどりつく ( どこをどのように進むか、あらかじめ決まっていない )

Page 7: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

プロジェクト管理のフレームワーク

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

他の開発手法に対する WrapperXP

Scrum

Page 8: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

Scrumによる開発の流れProduct Backlog

Sprint Backlog

Sprint 計画

Sprint デモ、レビュー

モデリング記法、ツール、ガイドラインなど

30-Day-Sprint

Daily Scrum

Page 9: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

Scrumの構成要素大きく 3 つのパートに分かれる Pre-Sprint

Sprint 計画 今回の Sprint の目標、 Backlog を定める

Sprint 30日の全力疾走

Daily Scrum でチェック Post-Sprint

Sprint レビュー 改善点洗い出し

上記サイクルを繰り返す ( インクリメント )

Page 10: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

Sprint計画

Product Backlog から、今回の Sprint の対象にするものを選択する XP での計画ゲーム 機能的、非機能的なもの、全てが Backlog

Story, Task の区別はない

Backlog の優先度を決めるのは Product Owner 必ず 1 人 顧客の重要メンバや製品開発マネージャなど

必要となる工数を見積もるのは Developer 作業の概要を決める

Page 11: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

Sprint(全力疾走 )

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

その Sprint が成功したかどうかは Sprint後のレビューで判断される

Page 12: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

Scrumの登場人物たちScrum Master アーキテクトではない チームが Sprint で直面する、様々な障害をとりのぞくことに注力する

要求の壁、設備の調達、 Daily Scrum 開催の準備など 開発を進めるための大きな権限を持つ

Decision Making Sprint の解散

Product Owner 中心となる顧客

Backlog の優先度を決める

Developer アナリスト、アーキテクト、プログラマを区別しない

Page 13: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

Daily Scrum Meeting(1)決まった時間に決まった場所で、毎日 15-30 分 だらだらしない ( できれば立って )

進捗確認、問題点の顕在化が目的 解決のためのミーティングとは別

Chickens & Pigs Chicken

直接開発に関わらない人々 ( 顧客、他チームの開発者など ) 見ているだけ、口出しはできない

Pig 開発の当事者

3 つの質問 前回の Scrum までにどんな作業をしたか ? 次の Scrum までにする作業は ? 作業の障害はないか ?

Page 14: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

Daily Scrum Meeting(2)実は単なるミーティングではない 進捗の単純な報告ならばメールで十分自己組織化のための原動力

チームのダイナミクスを皆が肌で感じる 良い点をどうのばし、悪い点をどう補っていったらよ

いか当事者意識とフィードバック機構を持った組織の強さ

Page 15: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

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

Page 16: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

BacklogProduct Backlog 全体の Backlog次々に追加優先度の高いものほど詳細に

Release Backlog マイルストーンとして特定期間で区切られた

Backlog

Sprint Backlog 30日の Sprint内で、実現すると定めた Backlog

Page 17: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

進捗の管理Sprint Backlog Graph あとどれだけの作業が累積で残されているか 正確な時間を見ているのではなく、今後の傾向をみて

いる

0

500

1000

1500

2000

2500

3000

1 5 10 15 20 25 30日にち

時間

Page 18: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

大規模への適用 (1)最初は 1 チームで作り、その後で依存性を考慮してブランチする ブランチしてできたチームは、オリジナルのメンバを必ず含

んでいる

必要に応じて、「共有リソースチーム」をつくる 開発チームから、安定している部分を吸い上げて、共通部品と

していくことが指名 むりやり共通部品を押しつけるのではない

Branch!

Page 19: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

大規模への適用 (2)

各チームは自己組織化している各チームに Scrum Masterそれぞれの Backlog をこなす

Scrum of Scrums を定期的 (1週間に 1回など ) に行い、調整を行う

Page 20: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

Scrumにおける価値Commitment 各Sprint でチームが何をできるか、ゴールを定め「契約」する

Focus Sprint内では Sprint の目標以外のことはしない

Openness 隠し立てしない 問題点は日頃の Scrum Meeting で、進捗は Sprint Review で

Respect 個々人の力を信じて、のばせるように動く

Courage 上記を実行するための勇気 チームを自己管理する勇気 自らをさらけ出す勇気

Page 21: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

XPとの大きな違い (1)

要求の扱いオンサイト顧客のプラクティスと、 Sprint の考え方は一見相反する

Embrace change しない ?プロジェクトの進め方の戦略に関しては、積極的に

変更を加えていく 日々の Scrumミーティング

顧客の要求に関してはある程度 Fix しておきたい Sprint 計画

Page 22: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

XPとの大きな違い (2)

要求の単位 XP では顧客に見える単位のストーリーと、開発者から見たときのタスクに分割されている

Scrum では、全てが Backlog よりシンプル タスクのような細かなレベルは、 Scrum の自己組織化

の立場からは、干渉しないでおくべきもの該当 Sprint に特定 Backlog が入るかどうかの区別はあ

Page 23: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

XPとの大きな違い (3)

責任の所在 XP では、 One Team として一蓮托生で進む Scrum では、 Scrum Master 、 Product Owner の権限がより、強化されている

責任も重い性善説に立たない政治的な部分に対する配慮

Page 24: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

XPとの大きな違い (4)

イテレーションの単位 XP では 2-3 ヶ月のリリースの中に 1-3週間のイテ

レーションが入る Scrum は、機械的に割り振られた Sprint がフラット

な形で並ぶ 一定期間の中で、できることを定義し、その実現に集中す

る Scrum Goal が、イテレーション内の工数のぶれの調整の役割を果たす

イテレーションは複数のストーリーを実現させるものではなく、一つの Goal を実現させるもの

計画にかかるオーバーヘッドの削減

Page 25: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

XPプロジェクトの概要概要 期間 : 2001/10/1~ 2002/3/31 ドメイン :

組み込み向け分散OS プロト  チーム構成 :

プロキシ顧客 藤沼さん ( イイガ )

開発者 阿部さん ( オブジェクトディメンション ) 西原さん (SRA) 梅澤 ( 豆蔵 ) 南谷君 ( 豆蔵 ) 寺田さん ( イイガ )

Page 26: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

XPプロジェクトのもたらしたもの

士気の大幅な向上楽しくてしょうがないノリノリ

ちょっと怖いくらい

開発効率の向上 1日単位の細かなスケジューリング

無駄なことは一切していない 1 ヶ月目で、基本的なシステムの骨組みはできあがる 2 ヶ月目にはほぼ当初のストーリーをつぶし、後半は安定性を高めことに集中

結果として 1 ヶ月ほどの余裕ができた ドキュメント作成にあてる

Page 27: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

XPプロジェクトの問題点Test First を実践できないテストの数が十分でない大きな視点からのデザインレビューの不足 とにかく動けばよい 保守的な側面がないがしろに ビッグリファクタリングではまる

ニューカマーに対する教育 ペアプロだけでは… コーチが開発にまきこまれる

燃えつき感ストーリーが出てこないと開発が止まる

Page 28: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

Standup Meeting以前

Standup Meeting 以前は…ペアの交代の感覚が長くなりがち

問題点がペア内に隠蔽されるインテグレーションのコストが全般に増

す異なるペアの間でのデザインの乖離

タスクの管理があいまいだらだらしてしまい、全速力にならない

Page 29: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

Standup Meeting以後Standup Meeting後では…前回の XP プロジェクトの反省をふまえ、 Standup Meeting

を行うことにした該当タスクについて昨日はどんな作業をしたか ?タスクについて今日は何をするか ?

だれとパートナーをくむか ? どの新規タスクを選ぶか ?

問題点として何があるか このクラスはいけていないのでリファクタリングしよう

利点 :緊張感と達成感

進捗の管理、やる気の維持に非常に有効

Page 30: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

Standup Meetingでの反省点 (1)

決まった時間に、決まった場所で…必ずしも守れなかった

遅刻メンバ新規参加メンバ

午後行うようにしてみたが… ろくなことがない午前中は、まったり

士気の低下勝手なソロプロの助長

インテグレーションコストの増大

Page 31: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

Standup Meetingでの反省点 (2)

Scrum Master 不在での Standup Meeting問題の解決は皆で行ったが…

解決者があいまいになりがち指摘はメンバからあるものの、ほっておかれ

ることもあった

Page 32: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

その他の Scrumのプラクティス適用

Post Sprint Meeting ( のまねごと )イテレーション間で休む

燃え尽きるので週 40 時間は実施が難しい

きちんとしたレビューを行うということまでには至らなかった

最終的な反省会は行ったが、時は既に遅し

Page 33: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

今後の Scrumのプラクティス適用

7 月から新 XP プロジェクトが始まる Scrum Master 、 Product Owner の任命 Daily Scrum の実施

より問題点の指摘を明確に イテレーション間で、振り返りのため

Post Sprintミーティングを行う要求管理も Backlog で行く今回のプロジェクトの性質上

製品内製に近い むしろ要求を自ら作り出していかねばならないお客さんと仲が悪いわけでもない

Page 34: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

まとめ

XP は開発者が Agile になるためのものScrum は、マネージャが Agile になるためのもの Agile な手法で特に“マネージャ“の役割を明確化した功績は大きい

XP で背後に隠れている“Agile なマネージャ”をクローズアップした

要求管理やマネージメント的側面から攻めると、 XP よりも上司を説得しやすいであろう

XP が内在している破壊的な部分の補強剤となるであろう

Page 35: Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)

URLScrum 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.pdf

Scrum + XP xP@Scrum

http://www.controlchaos.com/xpScrum.htm Xbreed

http://www.xbreed.net