いらすとやで理解するスクラム用語（スクラムガイド2020Update版） / learning_scrum_term_for_beginner_by_irasutoya

スクラムの根源的な考え、役割、イベント、成果物などについて、簡潔に理解した気になるような資料です。本格的な理解はスクラムガイド2020版をご覧ください。

1. いらすと(や)で理解する スクラム 用語 ～スクラムガイド 2020 アップデート版～
2. このスライドって何？ “スクラムの基本的な用語” を “イメージ(心)で理解する” そんな資料です。 (誇張アリ) 2 だ け で な く で も スライドを見終わった人 スクラムガイド 2020の改定に合わせて用語などをアップデートしました。 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
3. このスライドって誰向け？ チョットデキル 完全に理解した なにもわからない 初心者 「完全に理解した」 製品を利用をするためのチュートリアルを完了できたという意味。 「なにもわからない」 製品が本質的に抱える問題に直面するほど熟知が進んだという意味。 「チョットデキル」 同じ製品を自分でも１から作れるという意味。または開発者本人。 https://togetter.com/li/1268851 エンジニアの言う「完全に理解した」「なにもわからない」 「チョットデキル」って本当はこういう意味？より このへんが ターゲット 3 真の理解
4. スライドの見かた 背景が「白」 スクラムの公式ルール 背景が「黄」 補足する用語など 印刷用の印 4 用語のイメージのスライドと、用語の説明スライドの 2ページで１セットとなっています。
5. 免責 • このスライドは、スクラムの初学者向けに 基本的・教科書的な内容を中心に記載したものです。 • より実践的な内容については、公式ガイドやWebや 他の資料などをご覧ください。 • 極力一般的な整理や表現を用いるよう 気を付けてますが、万が一気になる点が ございましたらご容赦ください。 5
6. スクラムの全体像と スクラムの用語一覧 6
7. スクラムとは •複雑な問題に対応する適応型のソリューション •人々、チーム、組織 が価値を生み出すための 軽量級フレームワーク 7 （スクラム公式ガイドより） 手段と目的を取り違えない。スクラム が状況に不適合であればやめる選択も
8. 続・スクラムとは 8 経験主義とリーン思考に基づいて 反復的で漸進的なアプローチを用いて 最小のアウトプットで、 (作成物：作成物,機能) 最大のアウトカムを得る (成果：利益,価値) 開発手法/価値創造手法 詳しく知りたい人はスクラムガイド 自体も読んでください
9. 続・スクラムとは（補足） • 経験主義 • 知識は経験から⽣まれるため、 意思決定は観察・経験を元に行う • リーン思考 • ムダを省き、本質に集中する • 反復的 • 繰り返しにより状況の変化を把握し やすくする • 漸進的 • チームにとって良い状態を目指して 着実に改善していく 9
10. スプリント( Sprint ) スクラムの全体像 （イベントの関係図） 10 〇×△!! ◎△＄♪×￥ ◦＆％＃？ スプリントプランニング ( Sprint Planning ) デイリースクラム ( Daily Scrum ) スプリントレビュー ( Sprint Review ) スプリントレトロスペクティブ ( Sprint Retrospective ) プロダクトバックログ ( Product Backlog ) リリース可能な状態の プロダクト ( Potentially Shippable Product Increment ) 完成の定義 ( Done ) プロダクトオーナー ( Product Owner ) スクラムマスター ( Scrum Master ) 開発者 ( Developers ) ステークホルダー ( Stakeholder ) • スクラムの役割+α • スクラムの作成物 • スクラムのイベント 受け入れ基準 ( Acceptance Criteria ) 障害リスト ( Impediment List ) プロダクトバックログの見直し ( Product Backlog Refinement ) スプリントバックログ ( Sprint Backlog )
11. スクラムの全体像 （イメージのみ） 11 〇×△!! ◎△＄♪×￥ ◦＆％＃？
12. 用語一覧 分類 用語（和訳・意訳） 用語（原文） 基本用語 補足用語 * スクラムの3本柱 透明性 Transparency 〇 検査 Inspect 〇 適応 Adapt 〇 スクラムの5つの価値基準 確約 Commitment 〇 勇気 Courage 〇 集中 Focus 〇 公開 Openness 〇 尊敬 Respect 〇 スクラムの役割 開発者 Developers (7+-2) 〇 プロダクトオーナー Product Owner 〇 スクラムマスター Scrum Master 〇 ステークホルダー Stakeholder 〇 スクラムの作成物 プロダクトバックログ Product Backlog 〇 スプリントバックログ Sprint Backlog 〇 インクリメント （リリース可能な状態のプロダクト） Increment 〇 完成の定義（＋Readyの定義） Done 〇 受け入れ基準 Acceptance Criteria 〇 障害リスト Impediment List 〇 スクラムのイベント スプリント Sprint (1-4 weeks) 〇 スプリントプランニング Sprint Planning 〇 デイリースクラム Daily Scrum 〇 スプリントレビュー Sprint Review 〇 スプリントレトロスペクティブ Sprint Retrospective 〇 プロダクトバックログ見直し Product Backlog Refinement 〇 スプリントの中止 Sprint Stop 〇 その他の用語 スプリントゴール Sprint Goal 〇 インクリメント Increment 〇 タイムボックス Time Box 〇 ベロシティ Velocity 〇 ツール インセプションデッキ Inception Deck 〇 ストーリーボード Storyboard 〇 バーンダウンチャート Burndown Chart 〇 プランニングポーカー Planning Poker 〇 23 10 12 これらのイメージ をつかむ * スクラムガイド2020でガイドの目次および内容に記載がないもの。
13. 以下、本編 13
14. スクラム魂 14
15. 15 • ３本柱 • ５つの価値基準
16. スクラムの３本柱 スクラムの本質として、 参加する全員が意識するべき振る舞い 根幹となる観点 16
17. 透明性（ Transparency ） 17
18. 透明性（ Transparency ） • スクラムの状況が”見える化”され認識が”共有”されていること。 • 見える化の仕組みが、標準化されており、見ている人同士が共 通理解を持つことができる状態であること。 共有事項の例 • プロセスの用語や手順を参加者全員で共有 • 作業する人と検査する人が「完成」の定義を共有 18
19. 検査（ Inspect ） 19
20. 検査（ Inspect ） • スクラムの進捗状況を適切に検査することで、現在の状態の良し悪 しの判断をすること。 • 好ましくない変化を早急に検知することが重要であり、スキルの高 い検査担当者が念入りに検査することで高い効果を発揮する。 • ただし、検査の頻度が高すぎると作業の妨げになることがある。 検査対象例 • スクラムの作成物 • スプリントゴールの進捗 20
21. 適応（ Adapt ） 21
22. 適応（ Adapt ） • スクラムのプロセスが ”悪い状況” に陥った際に、正しくスクラムが 機能するチーム状態となるように調整・改善を行うこと。 • “悪い状況” とは、スプリントで開発したプロダクトのリリースや受 け入れができないと判断された場合などを指す。 • 問題検知から調整までの間隔が短いほうが、全体進捗の逸脱を防ぐ ことができる。 調整対象例 • プロセス • スクラムの各種構成要素 22
23. スクラムの３本柱 透明性（Transparency） 検査（Inspect） 適応（Adapt） ～まとめ～ 23
24. スクラムの５つの 価値基準 スクラムの効果をより高めるために、 参加する全員が理解し、実践するべき心構え 24
25. 確約（Commitment） 25
26. 確約（Commitment） • 目的に対して真摯に取り組むこと。 • 特に、一緒にスクラムを実行するチームおよびスプリントゴー ルの達成を目指して献身的に取り組むという心構え。 • 「結果にコミットする」という表現は冗談抜きで適格。 26
27. 勇気（Courage） 27
28. 勇気（Courage） • 完璧なものはないと認める勇気。 • また、変化に対応する勇気を持つことでもある。 • 特に、自分の考えとチームの方向性が異なる場合があっても、 ゴール達成の観点からみて、自分のコダワリによって発⽣する 問題であれば、それを受け入れ、全体最適を優先した判断がで きる強い心を持つこと。 28
29. 集中（Focus） 29
30. 集中（Focus） • スクラムとしてのタスクの実行に集中すること。 • 特に、スプリント計画の立案や実施、スプリントゴールの達成 など、目の前にある、「まずやるべき」重要な事項に集中する という意識。 30
31. 公開（Openness） 31
32. 公開（Openness） • 自らの状態や課題を隠さずに共有すること。 • そもそもとして、あらゆる情報・考えを隠さない、 という心を持つこと。 • 特に、スクラム・スプリントの実行を妨げる事象を共有するこ とで、すばやい対処が実施できるなど、メンバー間の信頼関係 の醸成にも寄与する重要な価値観。 32
33. 尊敬（Respect） 33
34. 尊敬（Respect） • 自分と異なる人に対して、その多様性に敬意を払うこと。 • 特に、スクラムメンバーそれぞれのバックグラウンド、専門性、 洞察力に敬意を持ち接すること。 34
35. スクラムの５つの価値基準 確約（Commitment） 勇気（Courage） 集中（Focus） 公開（Openness） 尊敬（Respect） ～まとめ～ 35
36. スクラムの 基本ルール 36
37. 37 • 役割 • 作成物 • イベント
38. スクラムチームと ３つの役割 スクラムを実践する際の 役割・ロール 38
39. 開発者 ( Developers ) プロダクトオーナー ( Product Owner ) スクラムマスター ( Scrum Master ) 39 スクラムチーム
40. 開発者 ( Developers ) is the Better. 40
41. 開発者 ( Developers ) • スクラムで開発するプロダクトを開発・実装するエンジニア。 • １チーム＝３～９人で構成する。 （理想は７±２人と言われる） • 自己管理を重視し、3本柱や5つの価値基準に基づいて振る舞うこと。 • スクラムにおける開発者は、特定の技術に専門化した人材ではない。各人が複数 の役割を担え、機能横断的な相互協力のもとスクラムを実行する。 • メンバー間での上下関係はなく対等である。 • 全員で開発するプロダクトに責任を持つ。 41
42. プロダクトオーナー ( Product Owner ) I want… 42
43. プロダクトオーナー ( Product Owner ) • スクラムで開発するプロダクトの結果責任を取る人。 • プロダクトが提供する価値（≒プロダクトバックログ(後述)） の管理者であり、その優先順位の最終決定権限を持つ。 • 優先順位の検討は、スクラムチーム全員やステークホルダーと行う。 • プロジェクトに必ず１人必要。 • プロダクトの価値の最大化のために立ち振る舞う。ただし、開 発者に対しては、相談はできるが、指示・干渉はできない。 43
44. スクラムマスター ( Scrum Master ) 44
45. スクラムマスター ( Scrum Master ) • スクラムのプロセスがうまく回るように、プロダクトオーナーや開 発者を支援する人。 • ファシリテータ、コーチ、教育係、推進役などを担う。 • メンバーを強く牽引するタイプのリーダーシップではなく、メン バーの自立を促すサーバントリーダーシップの発揮が求められる。 • プロダクトオーナーや開発者との兼任は、立ち振る舞いが混乱する ため推奨されない。ただし、チーム全員がスクラムに習熟していく ことで、自然とスクラムマスターの役割は薄くなっていく。 • スクラムチーム内の問題対処だけでなく、外部からの妨害・影響に 対しても、障害リストを作成するなどし適切な対処を行う。 45 サーバントリーダーシップとは https://bizhint.jp/keyword/14197
46. ステークホルダー ( Stakeholder ) α 46
47. ステークホルダー ( Stakeholder ) • 開発依頼主(顧客)や連携する部門のトップなど スクラムチーム(※) の外部にいる利害関係者 ※ スクラムチーム … 開発者、プロダクトオーナー、スクラムマスター • ステークホルダーとスクラムチームは、プロダクトオーナーを介しての関 係を保ち、開発者への直接の指示や影響は徹底的に避ける。 • スクラムマスターは、この関係維持のための支援も行う。 • ステークホルダーの言いなりになる、無視する、勝手な忖度などはしないこと。 • ただし、スクラムの成果であるプロダクトのリリース・受け入れ先でもあ るため、スクラムの状況などは適切に共有することが重要である。 α 47
48. スクラムでの役割 プロダクトオーナー (Product Owner) スクラムマスター (Scrum Master) 開発者 (Developers) ステークホルダー (Stakeholder) ～まとめ～ 48 スクラムチーム 顧客/外部関係者
49. スクラムの作成物 スクラムのプロセス中に 作成するもの 49
50. プロダクトバックログ ( Product Backlog ) PBL 50
51. プロダクトバックログ ( Product Backlog ) • スクラムで開発するプロダクトに対して、顧客やステークホルダーが持つ様々な要件を集めたもの。 • 個々の要件は、プロダクトバックログアイテム（PBI）と呼ばれ、プロダクトバックログ（PBL）はその集合である。 • プロダクトバックログアイテムは、ストーリー形式で書くことが多く、ユーザーストーリーとも呼ばれる。 • プロダクトオーナーが、プロダクトバックログの管理に責任を持ち、またプロダクトゴールを策定し、スクラムチーム全体に明示的に伝 えることも重要である。 • プロダクトバックログの管理とは、プロダクトバックログアイテムの並び替えや改廃である。 • プロダクトバックログの管理作業やプロダクトバックログアイテムの作成は、プロダクトオーナーが行う場合もあれば開発者が行う場合もある。 全員で協力し合うことが成功の秘訣である。 • プロダクトバックログアイテムは、「他の要件に依存せず、それ単体でスケジュール可能」な粒度で記述する。 • プロダクトバックログアイテムは、優先度や相対的な見積もり(S,M,Lや重み：ストーリーポイント)を付けて管理する。 • プロダクトのリリースに必要な最小限のプロダクトバックログアイテムの集まりのことをMVP(Minimum Viable Product)と呼び、それ に加える価値として、他のプロダクトバックログアイテムの優先度を検討する。 • プロダクトバックログは、常にメンテナンスして最新に保つ。 • プロダクトバックログアイテムが技術的な視点に寄りすぎると、関連する全てのプロダクトバックログアイテムが揃わないとリリースで きなくなる、というリスクがあることに注意する。 • 最初から優先度の低いプロダクトバックログアイテムまでを詳細に洗い出すことはしない。優先度の高いものから行う。 • RFPをそのままPBLに落とし込むと、不要な要件までを含んでしまう可能性があることに注意する。 51
52. スプリントバックログ ( Sprint Backlog ) 52 SBL Sprint 2 Sprint N Sprint 1 SBL SBL PBL
53. スプリントバックログ ( Sprint Backlog ) • スプリントバックログ（SBL）とは、スプリント実行する対象となったプロダク トバックログアイテムを、実装・管理可能な”作業”まで詳細化・細分化したもの。 • スプリント（1～4週間）で実施するタスクの集合として管理する。 • 作業の残量を的確に把握できるように、1日以下の単位として見積もる。 • (理想的には) 計画したスプリントバックログの完遂＝スプリントゴールの達成となる。 • スプリントの期間が長くなると、一回のスプリントで消化するスプリントバック ログアイテムの数が多くなり、複雑度が増し、スプリントゴールが達成できない リスクが増える、ということに注意する。 • スプリントバックログには、開発・実装に直接的に関与しないプロダクトオー ナーのタスクは含めない。 53
54. インクリメント ( リリース可能な状態のプロダクト) ( Potentially Shippable Product Increment ) 54
55. • スプリントで開発したプロダクトのこと。 • スクラムは、動作する状態のプロダクトを繰り返し開発・改善 することで、その機能や品質を、顧客やステークホルダーが望 む状態に作り込む手法である。 • そのため、スプリントで開発したプロダクト＝リリース可能な 状態のプロダクト(＝動作する)であることが前提となる。 55 インクリメント ( リリース可能な状態のプロダクト) ( Potentially Shippable Product Increment )
56. 完成の定義 （Done） 56
57. 完成の定義（Done） • スプリントで開発するプロダクトの 完成指標・品質基準。 • プロダクトオーナーと開発者が決定し、 スクラムチーム全員で共有する。 • スプリント途中での定義縮小は品質低下 の原因となるため避ける。 • Doneの定義と呼ばれることもある。 • 指標となる項目例 • コードレビュー • チェックイン • 単体テスト • カバレッジ • ドキュメント • セキュリティ • 性能 • デプロイ など 57
58. Readyの定義 • 対象のプロダクトバックログアイテムがスプリントで開発される準備が 整っているかを定めた指標。 • Readyの定義を満たしていない状態でスプリントに入るリスクを、あらか じめ回避するための工夫。 • 完成の定義（Doneの定義）とセットで作られることが多い。 α 58
59. 受け入れ基準 ( Acceptance Criteria ) 59 ✔：Looks ✔：Function ✔：Performance ： Criteria List OK α
60. 受け入れ基準 ( Acceptance Criteria ) 60 • プロダクトオーナーや顧客が満足する品質や機能の基準。 • プロダクトバックログの要件ごとに、プロダクトオーナーや顧 客と認識を合わせたものを設定する。 • スプリントを繰り返し、プロダクトの品質や機能が この基準を満たすことで、正式にリリースされる。 • プロダクトオーナーや顧客が求める受け入れ基準まで、一回の スプリントで作り込められるようになれば、スプリント毎にリ リースができるようになる。 α
61. 障害リスト ( Impediment List ) 61 α
62. 障害リスト ( Impediment List ) 62 • スクラム/スプリントを進める上での 障害や妨害となる事項のこと。 • 人的なものから開発しているプロダク トまで、あらゆるものを対象とする。 • 「障害事項を除去することにフォーカ スしないことが一番の障害」と言われ るほどに重要な項目である。 • 障害・妨害事項の例 • 未完了なままの作業 • 情報の不足 • 繰り返しの作業 • 待ち • 依存先の欠如 • 割り込み • バグ • 官僚主義 • 間違ったコミュニケーション • 不明瞭なコミュニケーション • 意思決定がなされない • 間違った推定 • 時間がたりない • パーツがない • よく知らない新しい技術 α
63. スクラムの作成物（一覧：６個） •プロダクトバックログ ( Product Backlog ) •スプリントバックログ ( Sprint Backlog ) •リリース可能な状態のプロダクト ( Potentially Shippable Product Increment ) •完成の定義 ( Done )＋Readyの定義 •受け入れ基準 ( Acceptance Criteria ) •障害リスト ( Impediment List ) 63 ～まとめ～
64. スクラムの作成物 64 ～まとめ～ プロダクトバックログ ( Product Backlog ) 完成の定義 ( Done ) 受け入れ基準 ( Acceptance Criteria ) 〇×△!! ◎△＄♪×￥ ◦＆％＃？ 障害リスト ( Impediment List ) スプリントバックログ ( Sprint Backlog ) リリース可能な状態の プロダクト ( Potentially Shippable Product Increment )
65. スクラムの イベント スクラムのプロセスを構成する主要なイベント (この節の最後に、各イベントに参加する人の役割のまとめを記載) 65
66. スプリント ( Sprint ) 66 1～4 weeks
67. スプリント ( Sprint ) • スクラムにおける、開発の１サイクルのこと。 • 1週間～4週間かけて実施される。 • スクラムに慣れていないチームの場合、1週間スプリントとして短い期間で レトロスペクティブ（振り返り）の回数を稼ぐことでチーム全体としてのス クラムの理解を進めることが有効である。 • 期間の延長はせず、固定の期間を繰り返す。 • １回のスプリントの中で、計画・設計・開発・テスト・レビューと いったプロダクトのリリースに必要なすべてのイベントを実行する。 67
68. スプリントプランニング ( Sprint Planning ) 68 Step1 ～What～ Step2 ～How～
69. スプリントプランニング ( Sprint Planning ) • スプリントゴール(スプリントの開発目標)とスプリントバックログを作成する計画プロセス。 • 整理する観点ごとに次の２部構成で実施する場合もある。 • 第１部（What） • プロダクトオーナーが優先的に欲しい機能は何か、開発者としてはどれくらいが作れそうか、 という観点から、プロダクトバックログの中から次のスプリントで実施する項目を選択する。 • 第２部（How） • 選択したプロダクトバックログを、どうやって達成するのか、 という観点から、スプリントバックログとしてタスクを実行可能な レベル(＝タスクの単位：1日以下)まで詳細化する。 • 想定所要時間 • 1か月スプリント：8時間 • 2週間スプリント：4時間 • 開発者は、スプリントプランニングで合意した内容について 「完了させるために全力を尽くす」が「完了させることを保証するわけではない」 ことに注意する。 69
70. デイリースクラム ( Daily Scrum ) 70 Let’s Enjoy Today!!
71. デイリースクラム ( Daily Scrum ) • 開発者同士で進捗や課題などの認識や状況を共有する場。 • 簡潔な報告・共有が求められる。 • 前回のデイリースクラムからやったこと • 次回のデイリースクラムまでにやること • 困っていること • など • 毎日、同じ場所で、同じ時間に実施する。 • 朝会と呼ばれることが多いが、朝でなければいけないわけではない。 • 時間は厳守で、延長はしない。 • 想定所要時間 • 15分 • 共有の場であって、問題解決の場ではないことに注意する。 • 解決すべき問題が見つかった場合は、別途関係者のみで検討・対応する時間を設ける。 • 問題が複雑/影響が大きいなどの場合は、緊急処置(エマージェンシープロシージャ)として プロダクトオーナーも含めて対処法の検討を行う。 71
72. スプリントレビュー ( Sprint Review ) 72
73. スプリントレビュー ( Sprint Review ) • 各スプリントの終わりに、そのスプリントで開発したプロダクトに 対してレビュー/議論を行い、適正なフィードバックを共有する場。 • ステークホルダーからのフィードバックを受ける場でもある。 • 積極的に質問やフィードバックを行う姿勢が重要である。 • レビュー/議論の観点 • 動作するプロダクトの状態・品質・デモ • 前回のスプリントのプロダクトとの機能差分や作成量など • 想定所要時間 • 1か月スプリント：4時間 • 2週間スプリント：2時間 73
74. スプリントレトロスペクティブ ( Sprint Retrospective ) 74
75. スプリントレトロスペクティブ ( Sprint Retrospective ) • 各スプリントの終わりに、次のスプリントの質を向上させることを目的として、 そのスプリント全体について、スクラムチーム全員で振り返る場。 • プロセスやツールなどの観点も含めて検査し、今後のアクションプランを作る。 • 振り返りのポイント • うまくいったこと。 • 直面した課題とその解決策。 • 今後改善すべき点。 • など • 想定所要時間 • 1か月スプリント：4時間 • 2週間スプリント：2時間 • スプリントの終わりだけでなく、もっと短い周期やタイミングでの定点振り返りとして 実施してもよい。 75
76. プロダクトバックログの見直し ( Product Backlog Refinement ) 76 PBLRefine PBL α
77. プロダクトバックログの見直し ( Product Backlog Refinement ) 77 • プロダクトバックログについて、更新・追記・削除・詳細化・再見 積もり・優先度の変更などを行う。 • リリース済みのプロダクトにバグがあった場合、その対策を要件と してPBLに追加し、後続のスプリントで対処する。 • 開発中に見つかったバグは、そのスプリント内で速やかに解消すること。 • スプリントの進捗や顧客要求の変化に対応するための作業。 • スクラムチーム全員で取り組み、共有する。 • スプリントレビューやスプリントレトロスペクティブの後に行うこ とで、次のスプリントプランニングの精度を上げることができる。 α
78. スプリントの中止 ( Sprint Stop ) 78 α
79. スプリントの中止 ( Sprint Stop ) 79 • 実行中のスプリントを強制的に中止すること。 • スプリントの中止の権限は、プロダクトオーナーのみが持っている。 • 中止の判断は、スクラムチームやその他の関係者の意見を聴いた上で行う。 • スプリントの中止の判断例 • スプリントゴールが、市場の動向から明確にずれている／古くなった • スプリント自体の運営が根本的に機能しなくなった • スプリントの中止を実施した場合 • プロダクトバックログの「完了」した項目のレビューなど、現状の棚卸しを行う。 • スクラムを継続する場合、次のスプリントのスプリントプランニングを開催する。 • スプリントの中止は、多用は良くないが、決断すべき時は勇気をもって行う。 α
80. スクラムのイベント（一覧：７個） • スプリント ( Sprint ) • スプリントプランニング ( Sprint Planning ) • デイリースクラム ( Daily Scrum ) • スプリントレビュー ( Sprint Review ) • スプリントレトロスペクティブ ( Sprint Retrospective ) • プロダクトバックログの見直し ( Product Backlog Refinement ) • スプリントの中止 ( Sprint Stop ) 80 ～まとめ～
81. 81 スプリントプランニング ( Sprint Planning ) デイリースクラム ( Daily Scrum ) スプリントレビュー ( Sprint Review ) スプリントレトロスペクティブ ( Sprint Retrospective ) プロダクトバックログの見直し ( Product Backlog Refinement ) 開発者 ( Developers ) スプリントの中止 ( Sprint Stop ) スクラムのイベント ～まとめ～ スプリント( Sprint )
82. スクラムの主要なイベントへの出席者 82 役割 スプリント プランニング デイリー スクラム スプリント レビュー スプリント レトロスペクティブ プロダクトバッ クログの見直し 開発者 ◎ ◎ ◎ ◎ ◎ プロダクトオーナー ◎ △ ◎ ◎ ◎ スクラムマスター ◎ ◦ ◎ ◎ ◦ ステークホルダー △ △ ◦ △ △ https://www.ryuzee.com/contents/blog/3989 ～まとめ～
83. おまけ 83
84. 84 • その他の用語 • ツール スクラムに限らず、一般的な開発でも 使われているものもあります
85. その他の用語 スクラムやアジャイル開発で よく使われている用語や概念の一例 85
86. 86 スプリントゴール ( Sprint Goal ) α
87. スプリントゴール ( Sprint Goal ) • 実行中のスプリントの達成目標。 • スプリントバックログを実現することで達成される。 • なぜその機能を開発するのかという指針・動機となる。 α 87
88. インクリメント ( Increment ) Sprint 1 Sprint 2 Sprint N α 88 …
89. インクリメント ( Increment ) • スプリントレビューでのレビュー対象となる作成物。 • 実装・テストが完了しており、動作すること。 • スプリントを反復しながら順次機能を拡張していくため、 インクリメントという呼称で呼ばれるようになった。 • 本スライドで「プロダクト」と表記しているものと同じ。 リリース可能な状態のプロダクト ( Potentially Shippable Product Increment ) α 89
90. タイムボックス ( Time Box ) α 90 0.5h 2.0h 1.5h Task A Task B Task C
91. タイムボックス ( Time Box ) α • 「固定された期間・時間」のこと。 • プロセス・タスクにタイムボックスを設定し、その期間・時間を守ることを意識 して実行することで、漫然とした時間の浪費を避ける。 • タイムボックスの例 • リリースまでの期間 • 一回のスプリント期間 • スプリントプランニングにかける時間 • デイリースクラムにかける時間 • スプリントレトロスペクティブにかける時間 • スプリントレビューにかける時間 • プロダクトバックログの見直しにかける時間 • スクラムチーム全体としてタイムボックスを守れるように協力しあうことが重要。 91
92. ベロシティ ( Velocity ) α 92 ⑤ ⑤ ⑬ ① ① ⑧ ① ⑧ ⑱ Total sum is …
93. ベロシティ ( Velocity ) • 決められた期間の中で、届けることができる要求の量のこと。 • 各スプリントでの⽣産量として、”完成したプロダクトバックログ”の見積 りの合計値を使うことが多い。 • スプリントごとに合計値を収集することで、チームが安定して達成できる ベロシティを見定めることができるようになる。 • ベロシティはチームやスプリント固有の事情を加味した⽣産量であるため、 他のスプリントに適用したり、一般的な⽣産性の指標としての利用はでき ません α 93
94. スクラム/アジャイル で使われるツール スクラムやアジャイル開発で よく使われているツールの一例 自身の状況に応じて適切に活用・工夫する 94
95. インセプションデッキ (Inception Deck ) α 95 「ご近所さん」を探せ われわれは なぜここに いるのか やらないこ とリスト エレベー ターピッチ パッケージ デザイン 解決案を 描く 何を諦める のかをはっ きりさせる 夜も眠れなくなるような問題は 何だろう 期間を見極 める 何がどれだ け必要か Whyを明らかにする Howを明らかにする
96. インセプションデッキ (Inception Deck ) 96 • プロジェクトの全体像(目的、背景、優先順位、方向性等)を端的に伝えるためのドキュ メントのこと。 • スクラムではプロダクトバックログを作成する前のステークホルダーやプロダクトオー ナーと開発者の間での認識合わせに利用される。 • 顧客(ステークホルダー)と開発者の間で認識を合わせるべき重要な項目として、次の10 個の質問と答えから構成されている。 • われわれはなぜここにいるのか(Why1) • エレベーターピッチ（プロダクト自体や目的を簡潔に述べたもの）を作る(Why2) • パッケージデザイン（プロダクトの効能やキャッチコピー）を作る(Why3) • やらないことリストを作る(Why4) • 「ご近所さん」を探せ(Why5) • 解決案を描く(How1) • 夜も眠れなくなるような問題は何だろう(How2) • 期間を見極める(How3) • 何を諦めるのかをはっきりさせる(How4) • 何がどれだけ必要なのか(How5) α
97. ストーリーボード ( Storyboard ) TODO 作業中 レビュー中 完了 α 97
98. ストーリーボード ( Storyboard ) • タスクや課題を”見える化”するためのカンバン風のボード。 • スクラムボードと呼ぶこともある。 • スクラム/アジャイルの現場でよく活用されている。 • 縦軸 • 現在のイテレーションで実装するストーリー • 横軸 • ステータス：「TODO」「作業中」「レビュー中」「完了」など • デジタルよりアナログであるほうが効果が高いと言われている。 α 98
99. バーンダウンチャート ( Burndown Chart ) α 99
100. バーンダウンチャート ( Burndown Chart ) • 計画した作業がどの程度消化されているのかを視覚的に見せる グラフ表記法。右下がりのグラフとして表現される。 • 縦軸 • 残りの作業量 • 横軸 • 時間 • スプリントバックログの消化状況を”見える化”し、スプリント の進捗推移を予測する為などに利用されることが多い。 α 100
101. プランニングポーカー ( Planning Poker ) α 101
102. プランニングポーカー ( Planning Poker ) • 「1, 2, 3, 5, 8, 13,・・・」というフィボナッチ数列が記載されたカード • プロダクトバックログの各タスクの見積もりに使われることがあるツール。 • タスクごとに、開発者が「自分が考えるタスクの重み」として数字を選択・提示 する。 • 最も大きな数字と最も小さな数字を出した開発者は、自分が出した数字＝見積も りに対する根拠を述べ、全員でその意見を検討し、最も適切だと思われる見積も り数値を決定する。 • タスクの相対的な見積もりであり、プロジェクトごとにその基準は異なる。 • この相対的な見積もり量は「ストーリーポイント」とも呼ばれる。 • あくまでも、タスクごとの相対的な見積もりであるため、絶対的な工数の値を表 すわけではないことに注意する。 α 102
103. 最後に 103
104. アジャイルソフトウェア開発宣言 104 https://agilemanifesto.org/iso/ja/manifesto.html ～最後に～
105. 105 こ の は て し な く 遠 い ス ク ラ ム 坂 を よ … オ レ は よ う や く の ぼ り は じ め た ば か り だ か ら な Don't just Do Agile, Be Agile !!
106. 参考・謝辞 106
107. 参考文献・URL • スクラムガイド（公式ガイド） • https://scrumguides.org/docs/scrumguide/v2020/2020- Scrum-Guide-Japanese.pdf • Ryuzee.com • https://www.ryuzee.com/ • SCRUM BOOT CAMP THE BOOK • https://www.amazon.co.jp/dp/B00DIM6BMI/ 107
108. 謝辞 • いらすとや • https://www.irasutoya.com/ • 本資料のいらすとは、下記の利用規定に基づいて利用しています。 • https://www.irasutoya.com/p/terms.html • 以下、著作権法32条（引用）に則って掲示させていただいております。 • “ジョジョの奇妙な冒険”より引用した全ての画像の著作権は 荒木飛呂彦氏に帰属します。 • “男坂”より引用した全てのセリフの著作権は車田正美氏に帰属します。 108