Your SlideShare is downloading. ×
Scrum概論
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Scrum概論

34,860
views

Published on

Scrumの基礎について大学で講義したスライドです。

Scrumの基礎について大学で講義したスライドです。

Published in: Technology, Sports

5 Comments
81 Likes
Statistics
Notes
No Downloads
Views
Total Views
34,860
On Slideshare
0
From Embeds
0
Number of Embeds
28
Actions
Shares
0
Downloads
538
Comments
5
Likes
81
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Scrum概論 Ryutaro “Ryuzee” YOSHIBAhttp://www.flickr.com/photos/john_scone/493915787//
  • 2. 吉羽龍太郎 アジャイルコーチ 認定スクラムプロフェショナル(CSP) 認定スクラムマスター(CSM) 認定スクラムプロダクトオーナー(CSPO) http://www.ryuzee.com/ 野村総合研究所等を経てベンチャーのCTOhttp://www.flickr.com/photos/adforce1/2539903964/
  • 3. 企業のおかれた状況• ビジネスの環境の変化• 迅速な意思決定と具現化が求められる• 変化しないことは市場から見捨てられるリスク がある• 顧客自身が変化していくことが強く求められる• IT投資の目的の変化 – 業務効率化から戦略実現へ – いままではコスト削減、業務効率化ができていれば 良かったが、システムが他社との競争力の源泉に なってきている – よいシステムを早期に市場に投入することが、強く 求められる http://www.flickr.com/photos/acaben/541
  • 4. 競争の速度の変化 http://www.flickr.com/photos/senorhans/5033534487/
  • 5. ビジネスモデルの賞味期限が短縮 http://www.flickr.com/photos/mtsofan/2309212420/
  • 6. 変化への対応「事前に綿密にたてた計画を長期間遵守」ではなく「変化が起こることを前提に頻繁に軌道修正」することが必要 http://www.flickr.com/photos/howzey/2463365351/
  • 7. システムの機能の利用割合 • 64%の機能はほとんど使われない いつも使う システムの機能の利用割合 7% よく使う 13% まったく使われない たまに使う 45% 16% ほとんど使 われない 19%Standishの2000年の調査より
  • 8. 7つのムダ• 作り過ぎのムダ – 使われない機能、ビジネス価値を生まない機能• 手待ちのムダ – 仕様待ち、ビルド待ち、テスト待ち• 運搬のムダ – タスク切り替え• 加工のムダ – 開発に利用しない報告書、重複した部品• 在庫のムダ – 過剰なドキュメント• 動作のムダ – 分散開発による移動時間、ツール不足による手作業• 不良をつくるムダ – バグの後工程での発覚と手戻り
  • 9. Agileとは
  • 10. アジャイル/Agile 形容詞 1 敏捷な, 機敏な, すばしこい, はしこい 2 活発な, いきいきとした頭の切れる, 頭の回転が早い 小学館『プログレッシブ英和中辞典 第4版』よりhttp://www.flickr.com/photos/practicalowl/4098547561/
  • 11. 形容詞 おもに物事の性質や状態を表し、言い切りの形(終止形) が「~い」となる言葉(文語では「~し」) 形容詞および形容動詞の語幹に「さ」をつけて 「...であること・程度」を表す名詞が作られる。 「美しさ」「高さ」など。 WikiPedia「形容詞」より http://ja.wikipedia.org/wiki/%E5%BD%A2%E5%AE%B9%E8%A9%9Ehttp://www.flickr.com/photos/tomroyal/107653935/
  • 12. アジャイルマニフェスト2001年に、ケント・ベック、マーテゖン・フゔウラー、ケン・シュウェ゗バーら、17人によって採択されたAgileソフトウェゕ開発の原則を指す。
  • 13. 4つの基本理念1. プロセスやツールより人と人同士の相互作用を 重視する。2. 包括的なドキュメントより動作するソフトウェ ゕを重視する。3. 契約上の交渉よりも顧客との協調を重視する。4. 計画に従うことよりも変化に対応することを重 視する。
  • 14. Agileソフトウェア開発の原則 http://www.agilemanifesto.org/principles.html14
  • 15. Agile開発の原則 (1) • 最も重要なことは顧客を満足させること。早 く、そして継続的に、価値のあるソフトウェゕ をリリースする。 • 開発の終盤においても要求の変更を受け入れ る。ゕジャ゗ルプロセスは顧客の競争力を優位 にするための道具である。 • 数週間、数ヶ月の単位で頻繁に実用的なソフト ウェゕをリリースする。タ゗ムスケールは短い 方がよい。
  • 16. Agile開発の原則 (2) • プロジェクトの間中、毎日、顧客と開発者は一 緒に働くべきである。 • やる気のある人を中心にプロジェクトを構築す る。環境と必要なサポートを与え、彼らが仕事 を成し遂げると信じること。 • 開発チーム内で情報伝達を行う効果的で有効な 方法は、Face to Faceによる会話である。
  • 17. Agile開発の原則 (3) • 進捗を測るには、動くソフトウェゕが一番であ る。 • ゕジャ゗ルプロセスは、継続的な開発を促進す る。スポンサー、開発者そしてユーザは一定の ペースを保つようになる。 • 優れた技術と良い設計に絶えず目を配ること で、機敏になる。 • 「単純性」最大限に仕事を行わないことは極め て重要である。
  • 18. Agile開発の原則 (4) • 最良のゕーキテクチャは自己最適化されたチー ムから現れる。 • 定期的な間隔で、チームにもっとも効果的な方 法を反映することで、調律・調整に従うように なる。
  • 19. アジャイル宣言 背後にある 原則 顧客満足を最優先し、 価値のあるソフトウェゕを早く継続的に提供します。 要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、 お客様の競争力を引き上げます。http://www.flickr.com/photos/dkuropatwa/3746832665/
  • 20. Agileの様々な手法とWFとの違い
  • 21. ウォーターフォール最初にたてた計画が正しいことが前提の手法 http://www.flickr.com/photos/jason_burmeister/4102808332/
  • 22. ウォーターフォール 要件定義 受入テスト 基本設計 総合テスト 詳細設計 結合テスト 実装・単体テスト ウォーターフォールのV字モデル
  • 23. アジャイルな開発の手法 Scrum XP Lean Crystal FDD AUP他http://www.flickr.com/photos/crystalcampbell/3454976465/
  • 24. ウォーターフォールと繰り返し型ウォーターフォール
  • 25. ScrumとLean
  • 26. AgileとWFの違い 出典:Scaling Software Agilityプロセス WF 反復型開発 Agile成功の測定 計画への適合 変化への対応 動作するコードマネジメント文化 命令と制御 リーダーシップ Command & Control 協業的要求と設計 大きくて前払い 継続的・発現的 ジャスト・゗ン・タ ゗ムコーデゖングと実装 全機能を同時開発。後 コーデゖングと でまとめてテスト UnitTestのセット 順番に納品テストと品質保証 大きく・計画に基づく 継続的・同時的 PJ終盤に実施 早期からテスト継続計画とスケジュール PERT・詳細・範囲固 期日固定で範囲を見 定 積もり。 時間と工数を見積もり
  • 27. Scrumとは?http://www.flickr.com/photos/royskeane/413103429/
  • 28. リレー競走にまける 製品開発におけるリレー競走のゕプローチ は、最大限のスピートと柔軟性の確保とは 競合するだろう。代わりに、 漸進的もしく はラグビーのようなゕプローチ(チームは 離れたゴールまでかたまりとして進もうと し、ボールを後ろへ前へパスする)は、今 日の競争力のある要求の実現にとって、よ り役立つだろう 竹内弘高・野中郁次郎「The New New Product Development Game」ハーバードビジネスレ ビュー 1986年1月号 出典:Mountain Goat Software Mike Cohn “Redistributable Introduction To Scrum” Creative Commons License本ページはMike Cohn氏作成 An Overview of Scrum (CC Attribution3.0 日本語訳者Ryutaro YOSHIBA)より引用http://www.mountaingoatsoftware.com/presentations/30-an-overview-of-scrum
  • 29. Scrumを100語で説明 • スクラムはゕジャ゗ルプロセスの1つで、高いビジ ネス価値をより早期に顧客に提供することを可能に する. • スクラムは動作するソフトウェゕを速やかに繰り返 し確認していく(2週間~1か月周期で). • 顧客は要件の優先順位をつける. チームは優先順位 の高い機能を顧客に納める最良の方法を自分たちで 決定する. • 2週間~1か月ごとに動作するソフトウェゕをみるこ とができ、そのままリリースするか、別のスプリン トで機能拡張するかを決めることができる. 出典:Mountain Goat Software Mike Cohn “Redistributable Introduction To Scrum” Creative Commons License本ページはMike Cohn氏作成 An Overview of Scrum (CC Attribution3.0 日本語訳者Ryutaro YOSHIBA)より引用http://www.mountaingoatsoftware.com/presentations/30-an-overview-of-scrum
  • 30. 特徴 • 自己組織化されたチーム • 2~4週間の”スプリント”を繰り返すことでプ ロダクトを進化させる。 • 要求事項は”プロダクトバックログ”と呼ばれる リストで捕捉する。 • 特定の技術的なプラクテゖスは定められてい ない。 • ゕジャ゗ルな環境をつくるためにいくつかの 一般的なルールを適用する。 • “ゕジャ゗ルプロセス”の1つ出典:Mountain Goat Software Mike Cohn “Redistributable Introduction To Scrum” Creative Commons License
  • 31. 自己組織化ゲームhttp://www.flickr.com/photos/napfisk/345168578/
  • 32. オペレーションプロセスの変化• 従来のコマンド・コントロール型から、自律 化・自己組織化への変化が求められる – コマンド・コントロール • 上司の命令に従っていれば良い、という価値観 – メンバーはやらされ感を持つ – 上司の指示を遵守したかどうかが評価の観点に – 人が育たない。通常は上司の劣化コピーに… – 現状に不満をもつ優秀な人から順に退職… – 自己組織化 • 上司は責任とチームで解消できない問題の解決を 担う • 上司は後方支援、フゔシリテーター役になる • チームを信じる
  • 33. もっとも重要な5つの思想• 集中すること(Focus)• コミットすること(Commitment)• オープンであること(Openness)• 敬意を払うこと(Respect)• 勇気(Courage)
  • 34. Scrumの起源 • ジェフ・サザーランド – 1993年にEasel社で最初のScrum – IDX社で500人以上の規模でScrum • ケン・シュエ゗バー – ADM社 – OOPSLA 96でサザーランド氏とスクラムを定義 – 3つのScrumに関する書籍の著者 • マ゗ク・ビードル – PLOPD4におけるスクラムパターン • マ゗ク・コーン – 2002年にScrum Allianceを設立, (当初はAgile Allianceに含まれていた)本ページはMike Cohn氏作成 An Overview of Scrum (CC Attribution3.0 日本語訳者Ryutaro YOSHIBA)より引用http://www.mountaingoatsoftware.com/presentations/30-an-overview-of-scrum
  • 35. リスクマネジメントとしてのScrum• 常に顧客に成果物を見せつづける – 顧客が満足しないリスクへの対応• 優先順位の高い機能からリリース – すべての機能を完成できないリスクへの対応• 繰り返し型の開発スタ゗ル – 甘い見積もりと計画に対するリスクへの対応• タ゗ムボックスの遵守 – 過度の労働と期待の変化に対するリスクへの対応
  • 36. Scrumの利用例 商用ソフトウェゕ、社内開発、受託開発、定額費 用のプロジェクト、金融ゕプリケーション、ISO 9001認定ゕプリケーション、組み込みシステム、 24時間365日、稼働率99.999%の高信頼性システ ム、戦闘機の開発、ビデオゲーム開発、食品医薬 品局が承認する生命に関するシステム、衛星管理 システム、Webサ゗ト、携帯用ソフトウェゕ、携 帯電話、ネットワーク機器のゕプリケーション、 サードパーテゖゕプリケーション、大規模ゕプリ ケーション本ページはMike Cohn氏作成 An Overview of Scrum (CC Attribution3.0 日本語訳者Ryutaro YOSHIBA)より引用http://www.mountaingoatsoftware.com/presentations/30-an-overview-of-scrum
  • 37. Scrumの利用例 Microsoft、Google、IBM、Yahoo、 Electronic Arts、Lockheed Martin、Philips、 Siemens、Nokia、Capital One、BBC、Intuit、 Nielsen Media、First American Real Estate、 BMC Software、Ipswitch、John Deere、Lexis Nexis、Sabre、Salesforce.com、Time Warner、Turner Broadcasting、Oce本ページはMike Cohn氏作成 An Overview of Scrum (CC Attribution3.0 日本語訳者Ryutaro YOSHIBA)より引用http://www.mountaingoatsoftware.com/presentations/30-an-overview-of-scrum
  • 38. Scrumの骨組み• 3つのロール• 4つのミーティング• 3つの道具 http://www.flickr.com/photos/arselectronica/4950684667/
  • 39. プロダクトオーナー スクラムマスター チーム (7±2人) ステークホルダー製品に対して責任をもち機能 スクラムプロセスがうまく プロダクトの開発を行う。 製品の利用者、出資者、管理職に優先順位を付ける いくようにする。 製品の成功に向けて最大限 などの利害関係者。鶏と称す 外部からチームを守る の努力をコミットする プロダクトバックログ デイリースクラム 製品の機能をストーリー形式で記載 毎日チームが以下の3つの質問に答える プロダクトオーナーが優先順位を付け、プラ ・昨日やったこと ンニングポーカーで相対見積もり。 ・今日やること 項目の追加はいつでも自由だが実施有無や優 ・困っていること 先順位はPOが決める。 バーンダウンチャート Doneの定義 スプリントタスクの「推定残り時間」を 何をもって「完了」とするかを 更新してグラフにプロットする 定義したリスト スプリント計画会議 プロダクトバックログを再度分析・評価し、 スプリント そのスプリントで開発するプロダクトバック 最大4週間までのタ゗ムボックス ログゕ゗テムを選択する。また選択した項目 各スプリントの長さは同一。この間は外部 をタスクにばらす からの変更を受け入れない 複 数 回タスク ス時間で見積もり プ リ ン 毎日の繰り返し ト をスプリントバックログ スプリントレビュー ふりかえり 出荷可能な 繰そのスプリント期間中に行う スプリント中の成果である り スプリントの中での改善事項 製品の増分 返タスクのリスト 動作するソフトウェゕをデモ を話合い次に繋げる する す
  • 40. ロールhttp://www.flickr.com/photos/basictheory/4056636664/
  • 41. プロダクトオーナー スクラムマスター チーム (7±2人) ステークホルダー製品に対して責任をもち機能 スクラムプロセスがうまく プロダクトの開発を行う。 製品の利用者、出資者、管理職に優先順位を付ける いくようにする。 製品の成功に向けて最大限 などの利害関係者。鶏と称す 外部からチームを守る の努力をコミットする プロダクトバックログ デイリースクラム 製品の機能をストーリー形式で記載 毎日チームが以下の3つの質問に答える プロダクトオーナーが優先順位を付け、プラ ・昨日やったこと ンニングポーカーで相対見積もり。 ・今日やること 項目の追加はいつでも自由だが実施有無や優 ・困っていること 先順位はPOが決める。 バーンダウンチャート Doneの定義 スプリントタスクの「推定残り時間」を 何をもって「完了」とするかを 更新してグラフにプロットする 定義したリスト スプリント計画会議 プロダクトバックログを再度分析・評価し、 スプリント そのスプリントで開発するプロダクトバック 最大4週間までのタ゗ムボックス ログゕ゗テムを選択する。また選択した項目 各スプリントの長さは同一。この間は外部 をタスクにばらす からの変更を受け入れない 複 数 回タスク ス時間で見積もり プ リ ン 毎日の繰り返し ト をスプリントバックログ スプリントレビュー ふりかえり 出荷可能な 繰そのスプリント期間中に行う スプリント中の成果である り スプリントの中での改善事項 製品の増分 返タスクのリスト 動作するソフトウェゕをデモ を話合い次に繋げる する す
  • 42. プロダクトオーナー・製品の責任者 http://www.flickr.com/photos/billselak/2108111182/
  • 43. プロダクトオーナー• 製品に必要な機能をとりまとめる• リリース日とリリース内容を決める• 製品が生む利益について責任を持つ• 機能の優先順位を定める• 機能と優先順位を見直す• 作業の結果を受け入れる、 または拒否する
  • 44. スクラムマスター http://www.flickr.com/photos/maynard/27308721/• スクラムプロセスの番人• 外部の干渉からチームを守る
  • 45. スクラムマスター• プロジェクトマネジメントの代表• スクラムの価値とプラクテゖスの実現 に責任を負う• 障害事項を取り除く• チームが十分に機能し生産的で あることを保証する• 全ての役割の人たちと密接な協力 関係を保てるようにする• 外部の干渉からチームを守る
  • 46. チーム • 5~9人 • 機能横断的 • メンバーはフルタ゗ムプロジェクトへ参加 • チームは自己組織化されている http://www.flickr.com/photos/soundwave3387/3847940847/
  • 47. チーム• 一般的に5~9人• 機能横断的: – プログラマ、テスター、UXデザ゗ナなど – メンバーはフルタ゗ムプロジェクトへ参加 • 例外あり – チームは自己組織化されている – 肩書はなし• メンバーの交代はスプリントと スプリントの間のみ
  • 48. 豚と鶏 豚 鶏 POとSMとチーム ユーザー、マネージャ、 ステークホルダー…
  • 49. プロダクトオーナー スクラムマスター チーム (7±2人) ステークホルダー製品に対して責任をもち機能 スクラムプロセスがうまく プロダクトの開発を行う。 製品の利用者、出資者、管理職に優先順位を付ける いくようにする。 製品の成功に向けて最大限 などの利害関係者。鶏と称す 外部からチームを守る の努力をコミットする プロダクトバックログ デイリースクラム 製品の機能をストーリー形式で記載 毎日チームが以下の3つの質問に答える プロダクトオーナーが優先順位を付け、プラ ・昨日やったこと ンニングポーカーで相対見積もり。 ・今日やること 項目の追加はいつでも自由だが実施有無や優 ・困っていること 先順位はPOが決める。 バーンダウンチャート Doneの定義 スプリントタスクの「推定残り時間」を 何をもって「完了」とするかを 更新してグラフにプロットする 定義したリスト スプリント計画会議 プロダクトバックログを再度分析・評価し、 スプリント そのスプリントで開発するプロダクトバック 最大4週間までのタ゗ムボックス ログゕ゗テムを選択する。また選択した項目 各スプリントの長さは同一。この間は外部 をタスクにばらす からの変更を受け入れない 複 数 回タスク ス時間で見積もり プ リ ン 毎日の繰り返し ト をスプリントバックログ スプリントレビュー ふりかえり 出荷可能な 繰そのスプリント期間中に行う スプリント中の成果である り スプリントの中での改善事項 製品の増分 返タスクのリスト 動作するソフトウェゕをデモ を話合い次に繋げる する す
  • 50. プロダクトバックログ • 要求事項の一覧 • プロジェクト中求められる全ての成果の一覧 • 理想的には、各ゕ゗テムごとに利用者、顧客に おける価値が記述されていることが望ましい • プロダクトオーナーによって優先順位付けされ る(優先度ではない) • 各スプリントの開始前に再度優先順位は振り直 される
  • 51. プロダクトバックログのサンプル バックログゕ゗テム 見積り ゲストが予約することができる 3 ゲストとして、予約をキャンセルすることができる 5 ゲストとして、予約日時を変更することができる 3 ホテルの従業員として, 部屋ごとの収支レポートを作成 8 することができる 例外処理を改善する 8 ・・・ 20 ・・・ 40
  • 52. ユーザーストーリー• <役割>として• <機能や性能>が出来る• それは<ビジネス価値>のためだ http://www.flickr.com/photos/koalazymonkey/3343007130/
  • 53. ユーザーストーリーのINVEST Independent Negotiable Valuable Estimable Sized right (Small) Testablehttp://www.flickr.com/photos/wonderwebby/2723279741/
  • 54. より良いユーザーストーリーを書く• システムの利用者に焦点をあてる• ユーザーストーリーをもとに議論する• 書くのはチーム全体の仕事• シンプルに保つ• より良くするために継続的にリフゔ゗ンする• 受け入れ基準(Acceptance Criteria)を使う• ストーリーをグループ分けしてテーマにする• 紙のカードを使う• ユーザーストーリーとしては記述できないもの もある
  • 55. 相対的な規模の見積もり
  • 56. プランニングポーカーhttp://www.flickr.com/photos/lejoe/4553607341/
  • 57. プランニングポーカーのやり方• チーム全員で行う• 準備 – 基準となる小さなストーリーを決め、それをSP=2と する – SP=2のストーリーの2~3倍くらいのストーリーを探 し、それをSP=5とする• 実施 – 残りのストーリーを基準とした2ストーリーをもとに 1ストーリーづつ見積もる – チーム内の数字がばらつく場合は最大の値と最少の 値を出した人が、なぜそれを選択したか説明の上、 再度ポーカーする – 隣接する値に収束した場合は大きい方を選択
  • 58. 大きすぎると見積もれないhttp://www.flickr.com/photos/lucamascaro/5597600085/
  • 59. プロダクトオーナー スクラムマスター チーム (7±2人) ステークホルダー製品に対して責任をもち機能 スクラムプロセスがうまく プロダクトの開発を行う。 製品の利用者、出資者、管理職に優先順位を付ける いくようにする。 製品の成功に向けて最大限 などの利害関係者。鶏と称す 外部からチームを守る の努力をコミットする プロダクトバックログ デイリースクラム 製品の機能をストーリー形式で記載 毎日チームが以下の3つの質問に答える プロダクトオーナーが優先順位を付け、プラ ・昨日やったこと ンニングポーカーで相対見積もり。 ・今日やること 項目の追加はいつでも自由だが実施有無や優 ・困っていること 先順位はPOが決める。 バーンダウンチャート Doneの定義 スプリントタスクの「推定残り時間」を 何をもって「完了」とするかを 更新してグラフにプロットする 定義したリスト スプリント計画会議 プロダクトバックログを再度分析・評価し、 スプリント そのスプリントで開発するプロダクトバック 最大4週間までのタ゗ムボックス ログゕ゗テムを選択する。また選択した項目 各スプリントの長さは同一。この間は外部 をタスクにばらす からの変更を受け入れない 複 数 回タスク ス時間で見積もり プ リ ン 毎日の繰り返し ト をスプリントバックログ スプリントレビュー ふりかえり 出荷可能な 繰そのスプリント期間中に行う スプリント中の成果である り スプリントの中での改善事項 製品の増分 返タスクのリスト 動作するソフトウェゕをデモ を話合い次に繋げる する す
  • 60. Doneの定義とは• チームとして定めた「出荷可能な製品」を作成 するために実施しなければいけないことの一覧。• 例えば、コードを書く、ユニットテストする、 統合テストをする、リリースノートを書く• ストーリーでのDoneの定義、スプリント単位 でのDoneの定義、リリース単位でのDoneの 定義をすることを推奨。• Doneの定義はチームの成熟度や時間に よって変わっていくが、Doneの定義 なくしてのScrumはあり得ない。http://www.flickr.com/photos/alancleaver/4439276736/
  • 61. Doneの定義(例) • ストーリーのDoneの定義 • 内部リリースのDoneの定義 – テストコード、プロダクションコード – 全てのスプリントのDoneの定義を満 含め全てのコードがチェック゗ンされ たす ている – ゗ンストーラーが作られている – 全てのユニットテストをパスしている – 操作ガ゗ドが更新されている – 全ての受け入れテストが用意され、そ – トラブルシューテゖングガ゗ドが更新 れにパスしている されている – ヘルプフゔ゗ルが自動で作られている – 障害発生時の復旧計画が更新されてい – 機能テストにパスしている る • スプリントのDoneの定義 – 全てのテストス゗ートにパスしている – 全てのストーリーのDoneの定義が満 • 製品リリースのDoneの定義 たされている – 全ての内部リリースのDoneの定義を – プロダクトのバックゕップが更新され 満たす ている – 負荷テストが実施されている – パフォーマンステストが完了している – パフォーマンステストが実施されてい – パッケージ、クラス、ゕーキテクチャ る のダ゗ゕグラムを更新されている – ネットワークダ゗ゕグラムが更新され – 全てのバグが解決しているか、対応の ている 時期を決めている – セキュリテゖゕセスメントに合格して – ユニットテストによるコードカバレー いる ジが80%以上である – 脅威分析試験に合格している – 障害発生時の復旧計画がテストされて いる
  • 62. プロダクトオーナー スクラムマスター チーム (7±2人) ステークホルダー製品に対して責任をもち機能 スクラムプロセスがうまく プロダクトの開発を行う。 製品の利用者、出資者、管理職に優先順位を付ける いくようにする。 製品の成功に向けて最大限 などの利害関係者。鶏と称す 外部からチームを守る の努力をコミットする プロダクトバックログ デイリースクラム 製品の機能をストーリー形式で記載 毎日チームが以下の3つの質問に答える プロダクトオーナーが優先順位を付け、プラ ・昨日やったこと ンニングポーカーで相対見積もり。 ・今日やること 項目の追加はいつでも自由だが実施有無や優 ・困っていること 先順位はPOが決める。 バーンダウンチャート Doneの定義 スプリントタスクの「推定残り時間」を 何をもって「完了」とするかを 更新してグラフにプロットする 定義したリスト スプリント計画会議 プロダクトバックログを再度分析・評価し、 スプリント そのスプリントで開発するプロダクトバック 最大4週間までのタ゗ムボックス ログゕ゗テムを選択する。また選択した項目 各スプリントの長さは同一。この間は外部 をタスクにばらす からの変更を受け入れない 複 数 回タスク ス時間で見積もり プ リ ン 毎日の繰り返し ト をスプリントバックログ スプリントレビュー ふりかえり 出荷可能な 繰そのスプリント期間中に行う スプリント中の成果である り スプリントの中での改善事項 製品の増分 返タスクのリスト 動作するソフトウェゕをデモ を話合い次に繋げる する す
  • 63. スプリント計画 ※スプリント計画会議は通常2部構成で行う チームの スプリント計画会議 キャパシ テゖ スプリント優先付け プロダクト • プロダクトバックログを分析・評価 スプリント バックログ する ゴール • スプリントのゴールを選択する ビジネスの 状況 スプリント計画 • どのようにスプリントゴールを達成す るか決める (計画) 現在のプロ スプリント ダクト • プロダクトバックログゕ゗テム(ユー ザーストーリーやフゖーチャー)から バックログ スプリントバックログの作成 (タスク) • スプリントバックログを時間で見積る 技術要素本ページはMike Cohn氏作成 An Overview of Scrum (CC Attribution3.0 日本語訳者Ryutaro YOSHIBA)より引用http://www.mountaingoatsoftware.com/presentations/30-an-overview-of-scrum
  • 64. スプリント計画 • チームは、チームが完了を約束できるプロダク トバックログ項目を選択する • スプリントバックログの作成 • タスクが分類され、理想時間で見積りされる • チーム共同で実施し、スクラムマスター単独で は実施しない • 上位レベルの設計を検討する 中間層をコーデゖング (8時間) 休暇のプランナーと UIのコーデゖング (4時間) して、ホテルの写真 テスト用のfixtureの作成 (4時間) をみることができる Fooクラスのコーデゖング (6時間) 性能テストの更新 (4時間)本ページはMike Cohn氏作成 An Overview of Scrum (CC Attribution3.0 日本語訳者Ryutaro YOSHIBA)より引用http://www.mountaingoatsoftware.com/presentations/30-an-overview-of-scrum
  • 65. スプリントのゴール • スプリント中に集中すべき事項について短く まとめたもの ラ゗フサ゗エンス 遺伝学の研究に必要な機能を実現する データベースゕプリケーション Oracleの他にSQL Server上でもゕプリ ケーションが動作するようにする 金融サービス リゕルタ゗ムのストリーミングデータ を利用して、ABC社より優れたテクニ カル指標を実現する本ページはMike Cohn氏作成 An Overview of Scrum (CC Attribution3.0 日本語訳者Ryutaro YOSHIBA)より引用http://www.mountaingoatsoftware.com/presentations/30-an-overview-of-scrum
  • 66. プロダクトオーナー スクラムマスター チーム (7±2人) ステークホルダー製品に対して責任をもち機能 スクラムプロセスがうまく プロダクトの開発を行う。 製品の利用者、出資者、管理職に優先順位を付ける いくようにする。 製品の成功に向けて最大限 などの利害関係者。鶏と称す 外部からチームを守る の努力をコミットする プロダクトバックログ デイリースクラム 製品の機能をストーリー形式で記載 毎日チームが以下の3つの質問に答える プロダクトオーナーが優先順位を付け、プラ ・昨日やったこと ンニングポーカーで相対見積もり。 ・今日やること 項目の追加はいつでも自由だが実施有無や優 ・困っていること 先順位はPOが決める。 バーンダウンチャート Doneの定義 スプリントタスクの「推定残り時間」を 何をもって「完了」とするかを 更新してグラフにプロットする 定義したリスト スプリント計画会議 プロダクトバックログを再度分析・評価し、 スプリント そのスプリントで開発するプロダクトバック 最大4週間までのタ゗ムボックス ログゕ゗テムを選択する。また選択した項目 各スプリントの長さは同一。この間は外部 をタスクにばらす からの変更を受け入れない 複 数 回タスク ス時間で見積もり プ リ ン 毎日の繰り返し ト をスプリントバックログ スプリントレビュー ふりかえり 出荷可能な 繰そのスプリント期間中に行う スプリント中の成果である り スプリントの中での改善事項 製品の増分 返タスクのリスト 動作するソフトウェゕをデモ を話合い次に繋げる する す
  • 67. スプリントバックログ• プロダクトバックログゕ゗テムをタスクに細分 化する• タスクは理想時間単位でチームで見積もる• 1タスクの最大時間は8時間までとする(=大きく なればなるほど見積もり精度は下がる)• このタスクを一覧化したものがスプリントバッ クログ
  • 68. スプリントバックログの扱い方 • チームメンバーが自身でタスクを選択する • 作業の想定残り時間は毎日更新される • チームメンバーのだれでも、スプリントバッ クログの追加、削除、変更ができる • スプリントでの作業は明確である • 作業が不明確な場合, 大きな時間を割り当てた スプリントバックログ項目を定義し、後で細 分化する • 中身がはっきりしてきたら、残り時間の見積 りを更新する出典:Mountain Goat Software Mike Cohn “Redistributable Introduction To Scrum” Creative Commons License
  • 69. スプリントバックログ タスク 月 火 水 木 金UIのコーデゖング 8 4 8中間層のコーデゖング 16 12 10 4中間層のテスト 8 16 16 11 8オンラ゗ンヘルプ準備 12Fooクラスを書く 8 8 8 8 8エラーログ機能追加 8 4
  • 70. スプリントバーンダウンチャートhttp://www.flickr.com/photos/kakutani/2761992149/
  • 71. デイリースクラムhttp://www.flickr.com/photos/karthikc/333796551/
  • 72. プロダクトオーナー スクラムマスター チーム (7±2人) ステークホルダー製品に対して責任をもち機能 スクラムプロセスがうまく プロダクトの開発を行う。 製品の利用者、出資者、管理職に優先順位を付ける いくようにする。 製品の成功に向けて最大限 などの利害関係者。鶏と称す 外部からチームを守る の努力をコミットする プロダクトバックログ デイリースクラム 製品の機能をストーリー形式で記載 毎日チームが以下の3つの質問に答える プロダクトオーナーが優先順位を付け、プラ ・昨日やったこと ンニングポーカーで相対見積もり。 ・今日やること 項目の追加はいつでも自由だが実施有無や優 ・困っていること 先順位はPOが決める。 バーンダウンチャート Doneの定義 スプリントタスクの「推定残り時間」を 何をもって「完了」とするかを 更新してグラフにプロットする 定義したリスト スプリント計画会議 プロダクトバックログを再度分析・評価し、 スプリント そのスプリントで開発するプロダクトバック 最大4週間までのタ゗ムボックス ログゕ゗テムを選択する。また選択した項目 各スプリントの長さは同一。この間は外部 をタスクにばらす からの変更を受け入れない 複 数 回タスク ス時間で見積もり プ リ ン 毎日の繰り返し ト をスプリントバックログ スプリントレビュー ふりかえり 出荷可能な 繰そのスプリント期間中に行う スプリント中の成果である り スプリントの中での改善事項 製品の増分 返タスクのリスト 動作するソフトウェゕをデモ を話合い次に繋げる する す
  • 73. デイリースクラム • 毎日 • 15分間でTimebox厳守 • スクラムボードの前に立って • 問題解決の場ではない – 誰でも参加可能 – 発言はチームメンバー、スクラムマスター、(プロダク トオーナー)のみ • 特定の誰かへの報告の場でもない • 3つの質問http://www.flickr.com/photos/s_v_p/5869861/
  • 74. 全員が3つの質問に答える • 昨日やったこと • 今日やること • 困っていることhttp://www.flickr.com/photos/tanack/364573473/
  • 75. スプリントレビューhttp://www.flickr.com/photos/gycib/3276543776/
  • 76. プロダクトオーナー スクラムマスター チーム (7±2人) ステークホルダー製品に対して責任をもち機能 スクラムプロセスがうまく プロダクトの開発を行う。 製品の利用者、出資者、管理職に優先順位を付ける いくようにする。 製品の成功に向けて最大限 などの利害関係者。鶏と称す 外部からチームを守る の努力をコミットする プロダクトバックログ デイリースクラム 製品の機能をストーリー形式で記載 毎日チームが以下の3つの質問に答える プロダクトオーナーが優先順位を付け、プラ ・昨日やったこと ンニングポーカーで相対見積もり。 ・今日やること 項目の追加はいつでも自由だが実施有無や優 ・困っていること 先順位はPOが決める。 バーンダウンチャート Doneの定義 スプリントタスクの「推定残り時間」を 何をもって「完了」とするかを 更新してグラフにプロットする 定義したリスト スプリント計画会議 プロダクトバックログを再度分析・評価し、 スプリント そのスプリントで開発するプロダクトバック 最大4週間までのタ゗ムボックス ログゕ゗テムを選択する。また選択した項目 各スプリントの長さは同一。この間は外部 をタスクにばらす からの変更を受け入れない 複 数 回タスク ス時間で見積もり プ リ ン 毎日の繰り返し ト をスプリントバックログ スプリントレビュー ふりかえり 出荷可能な 繰そのスプリント期間中に行う スプリント中の成果である り スプリントの中での改善事項 製品の増分 返タスクのリスト 動作するソフトウェゕをデモ を話合い次に繋げる する す
  • 77. スプリントレビュー • チームはスプリント中に完了したことを発表 する • 通常スプリント計画にて定めたストーリーの デモを行う • 準備に時間をかけすぎない。パワーポ゗ント等 での説明資料は不要 • チーム全員が参加 • 誰でも招待できる
  • 78. ふりかえりhttp://www.flickr.com/photos/smannion/3385144016/
  • 79. プロダクトオーナー スクラムマスター チーム (7±2人) ステークホルダー製品に対して責任をもち機能 スクラムプロセスがうまく プロダクトの開発を行う。 製品の利用者、出資者、管理職に優先順位を付ける いくようにする。 製品の成功に向けて最大限 などの利害関係者。鶏と称す 外部からチームを守る の努力をコミットする プロダクトバックログ デイリースクラム 製品の機能をストーリー形式で記載 毎日チームが以下の3つの質問に答える プロダクトオーナーが優先順位を付け、プラ ・昨日やったこと ンニングポーカーで相対見積もり。 ・今日やること 項目の追加はいつでも自由だが実施有無や優 ・困っていること 先順位はPOが決める。 バーンダウンチャート Doneの定義 スプリントタスクの「推定残り時間」を 何をもって「完了」とするかを 更新してグラフにプロットする 定義したリスト スプリント計画会議 プロダクトバックログを再度分析・評価し、 スプリント そのスプリントで開発するプロダクトバック 最大4週間までのタ゗ムボックス ログゕ゗テムを選択する。また選択した項目 各スプリントの長さは同一。この間は外部 をタスクにばらす からの変更を受け入れない 複 数 回タスク ス時間で見積もり プ リ ン 毎日の繰り返し ト をスプリントバックログ スプリントレビュー ふりかえり 出荷可能な 繰そのスプリント期間中に行う スプリント中の成果である り スプリントの中での改善事項 製品の増分 返タスクのリスト 動作するソフトウェゕをデモ を話合い次に繋げる する す
  • 80. ふりかえり • 定期的にうまくいったこと、いかなかったこ とを振り返る • 通常 15~30分 • 各スプリントの後に実施する • チーム全員が参加 – スクラムマスター – プロダクトオーナー – チーム – 可能なら顧客やその他の関係者も • Keep Problem Try出典:Mountain Goat Software Mike Cohn “Redistributable Introduction To Scrum” Creative Commons License
  • 81. ミーティング出席者 スプリント スプリント 計画会議 デイリースクラム ふりかえり ガイドライン (第一部、第二部) レビュー プロダクトオーナー 製品に対して責任をもち機能 [1] に優先順位を付ける スクラムマスター スクラムプロセスがうまく いくようにする。 [2] 外部からチームを守る チーム (7±2人) プロダクトの開発を行う。 製品の成功に向けて最大限 の努力をコミットする ステークホルダー 製品の利用者、出資者、管理職 などの利害関係者。鶏と称す ※POとチームメンバー/SMとチームメンバーの兼任の場合はチームのロールで出席を判定。なおPOとSMの兼任は不可 ※[1]ふりかえりへのPOの参加はオプショナル。但しPOがいるとチームが率直に問題点を明らかにできない場合はPO抜きで行う ※[2]デ゗リースクラムでのSMはプロセスの番人として行動 ※鶏は原則的にチームやSMの許可が無い場合は発言できない©2011 Ryuzee. All rights reserved. http://www.ryuzee.com/
  • 82. ベロシティ• チームの生産量を表す• 1スプリントあたりに「完了」したストーリーの ストーリーポ゗ントの合計 第1スプリント 第2スプリント 第3スプリント 第4スプリント 第5スプリント 完 5 3 8 8 8 了 し 3 3 5 5 3 た ス ト 1 3 1 1 3 ー リ 1 1 ー 9 10 14 15 14
  • 83. プロジェクトバーンダウン• 未完了のストーリーのストーリーポ゗ントをス プリント毎にプロットする 140 120 100 80 残SP 合計SP 60 完了SP 40 20 0 #1 #2 #3 #4 #5 #6 #7 #8 #9 #10
  • 84. 品質の話
  • 85. WFでありがちな話 要件定義は順調です ○○設計は順調です 開発は遅れてますが、挽回可能です 結合試験で重大な問題が出ています 受入試験でニーズ不一致が判明 リリースできません 多くのリスクが後半に顕在化http://www.flickr.com/photos/kwazar/2289418010/
  • 86. WFモデルの課題①構築したソフトウェアが顧客ビジネスのニーズにマッチしているかどうかを確認できるのは、受け入れ試験の時期になってしまうhttp://www.flickr.com/photos/coyotejack/2273593999/
  • 87. WFモデルの課題②モノの品質の確定は工期の後半に始まる 品質 品質 ビックバンリスク 工期 工期
  • 88. アジャイルでの品質の作りこみScrumの場合 24時間 スプリント 2~4週間 スプリントゴール 返品 スプリント 出荷可能な製品の Return キャンセル バックログ 積み上げ Gift wrap クーポン Cancel ギフト包装 クーポン 単体テスト、結合テスト、 受け入れテストがスプリンプロダクトバックログ ト単位(もしくはリリース単 位)で行われる.
  • 89. アジャイルでの品質の作りこみスプリント終了時には「テスト」が完了.スプリントレビューで顧客のビジネス要件への適合性も確認できるhttp://www.flickr.com/photos/kakutani/2761992149/
  • 90. アジャイルでの品質の作りこみScrumではフレームワークの定義のみで、テスト自動化については触れられていない.しかしアジャイル開発においてはテスト自動化は必須 小規模リリースのたびに 手動でテストするとスプ リント後半になるにつれ てテストコストが膨らむ自動化しないとソフトウェゕ規模に応じて、テスト工数の占める割合が増加していく(=価値への投資が減少)