Share
Embed
Slide 1
Slide 1 text
Scrum Training 2020
Slide 2
Slide 2 text
グループ決め
Breakout room割り当て
Slide 3
Slide 3 text
About me
• Yusuke Amano @ama_ch
• kintone Dev -> ScrumMaster
Slide 4
Slide 4 text
About me
• Toshiyuki Otomo @toshiotm
• 週2日サイボウズ勤務
Slide 5
Slide 5 text
Agile Coach Team
Slide 6
Slide 6 text
本日のゴール
• スクラムで定義されている役割・イベント・
成果物を理解する
• なぜ、スクラムで開発するのかを理解する
Slide 7
Slide 7 text
タイムテーブル
• 13:00-14:00 説明
• 14:15-14:45 各チーム議論
• 15:00-15:30 エクササイズ
• 15:45-16:00 Q&A
適宜休憩とQ&Aを挟みます
Slide 8
Slide 8 text
なぜスクラム?
Slide 9
Slide 9 text
ソフトウェア開発は不確実性が
高い
• コストと納期の見積もりは難しい
• 顧客自身も何がほしいのかわからない
• マーケットを先読みすることはできない
• 作る前に大きな意思決定をすることはリスク
が大きい（情報はあとから追加される）
Slide 10
Slide 10 text
Cynefin Framework
https://en.wikipedia.org/wiki/Cynefin_framework
ΫωϏϯϑϨʔϜϫʔΫ
https://www.slideshare.net/kiroh/ss-14929935
Slide 11
Slide 11 text
スクラムの概要
Slide 12
Slide 12 text
スクラムについて
• スクラムは、複雑なプロダクトを開発・提供・保守するため
のフレームワークである。
• 3つの役割、5つのイベント、3つの成果物
• スクラムの特徴:
• 軽量
• 理解が容易
• 習得は困難
Slide 13
Slide 13 text
プロジェクトマネージメントト
ライアングル
https://en.wikipedia.org/wiki/Project_management_triangle
Slide 14
Slide 14 text
No content
Slide 15
Slide 15 text
ϓϩμΫτΦʔφʔ
։ൃνʔϜ
εΫϥϜϚελʔ
ϓϩμΫτ
όοΫϩά
εϓϦϯτ
όοΫϩά
૿
σΠϦʔεΫϥϜ
;Γ͔͑Γ
εϓϦϯτ
ϓϥϯχϯά
εϓϦϯτ
ϨϏϡʔ
εϓϦϯτ
Slide 16
Slide 16 text
スクラムの価値基準
Slide 17
Slide 17 text
スクラムの3本柱
• 透明性
• 検査
• 適応
経験的プロセス制御の実現は、透明性・検査・適応の3本柱に
支えられている。
Slide 18
Slide 18 text
５つ価値基準
• 確約(Commitment)
• 勇気(Courage)
• 集中(Focus)
• 公開(Openness)
• 尊敬(Respect)
これらを実践するとき、スクラムの柱（透明性・検査・適
応）は現実のものとなり、あらゆる人に対する信頼が築かれ
る。
Slide 19
Slide 19 text
ス ク ラ ム を 活 用 す る に は 、 こ れ ら の 5 つ の 価 値 基
準 を 上 手 に 実 践 し な け れ ば い け な い 。 個 人 は 、 ス
ク ラ ム チ ー ム の ゴ ー ル の 達 成 を 確 約 し な け れ ば い
け な い 。 ス ク ラ ム チ ー ム の メ ン バ ー は 、 正 し い こ
と を す る 勇 気 を 持 ち 、 困 難 な 問 題 に 取 り 組 ま な
け れ ば い け な い 。 全 員 が 、 ス プ リ ン ト の 作 業 と ス
ク ラ ム チ ー ム の ゴ ー ル に 集 中 し な け れ ば い け な
い 。 ス ク ラ ム チ ー ム と ス テ ー ク ホ ル ダ ー は 、 す べ
て の 仕 事 と そ れ ら を 遂 行 す る 上 で の 課 題 を 公 開
す る こ と に 合 意 し な け れ ば い け な い 。 ス ク ラ ム
チ ー ム の メ ン バ ー は 、 お 互 い を 能 力 の あ る 独 立
し た 個 人 と し て 尊 敬 し な け れ ば い け な い 。
スクラムの価値基準
Slide 20
Slide 20 text
5つの価値基準
https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
• スクラムの理論(p.4)、スクラムの価値基準の
項目(p.5)を読んでください
• スクラムチーム内に5つの価値基準がないとき、
何が起こりますか？
• 各チームで議論してください
Slide 21
Slide 21 text
役割・イベント・成果物
Slide 22
Slide 22 text
プロダクトオーナー
Slide 23
Slide 23 text
役割1: プロダクトオーナー
• 開発チームから生み出されるプロダクトの価値の最大化に責任を持つ
• プロダクトバックログの管理に責任を持つ 1 人の人間である
• プロダクトバ ックログの管理には、以下のようなものがある:
• プロダクトバックログアイテムを明確に表現する
• ゴールとミッションを達成できるようにプロダクトバックログアイテムを並
び替える
• 開発チームが行う作業の価値を最適化する
• プロダクトバックログを全員に見える化・透明化・明確化し、スクラムチー
ムが次に行う作業を示す
• 必要とされるレベルでプロダクトバックログアイテムを開発チームに理解し
てもらう
Slide 24
Slide 24 text
プロダクトオーナー
• プロダクトオーナーの項目(p.5)を読んでくだ
さい
• POがプロダクトバックログマネジメントをし
ないと何が起こりますか？
• 各チームで議論してください
https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
Slide 25
Slide 25 text
開発チーム
Slide 26
Slide 26 text
役割2: 開発チーム
• 各スプリントの終了時にリリース判断可能な「完成」したプロダクトインクリメントを届け
ることのできる専門家で構成されている
• 自分たちの作業を構成・管理するために、組織から体制と権限を与えられている
• その相乗効果によって、開発チーム全体の効率と効果が最適化される
• 開発チームには、以下のような特徴がある:
• 自己組織化されている。プロダクトバックログをリリース判断可能な機能のインクリメ
ントに変える方法は、誰も（スクラムマスターでさえも）教えてくれない。
• 機能横断的である。インクリメントを作成するスキルをチームとしてすべて備えている。
• ある人にしかできない作業があったとしても、スクラムにおける開発チームのメンバー
に肩書きはない。
• テスティング、アーキテクチャ、運用、ビジネス分析のような専門領域であっても、ス
クラムは開発チームのサブチームを認めていない。
• 開発チームのメンバーに専門能力や専門分野があったとしても、最終的な責任は開発
チーム全体が持つ。
Slide 27
Slide 27 text
開発チーム
• 開発チームの項目(p.6)を読んでください
• 自己組織化されていない開発チームはどうな
りますか？
• 職能横断的でない開発チームはどうなります
か？
• 各チームで議論してください
https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
Slide 28
Slide 28 text
スクラムマスター
Slide 29
Slide 29 text
役割3: スクラムマスター
• スクラムガイドで定義されたスクラムの促進と支援に責任を
持つ
• スクラムの理論・プラクティス・ルール・価値基準を全員に
理解してもらえるように支援することで、その責任を果たす
• スクラムチームのサーバントリーダーである
• さまざまな形でプロダクトオーナーを支援する
• さまざまな形で開発チームを支援する
• さまざまな形で組織を支援する
Slide 30
Slide 30 text
参考動画:
https://youtu.be/NcWDx-XXISY
Slide 31
Slide 31 text
成果物1: プロダクトバックログ
• プロダクトに必要だと把握しているも
のをすべて順番に並べた一覧
• 価値が高いものから順番に並べる
• プロダクトバックログは決して完成し
ない（リファインメントを通じて絶え
ず手入れする）
• 並び順が上のアイテムほど明確で詳細
ϑΟʔνϟʔ"
ϑΟʔνϟʔ#
ϑΟʔνϟʔ$
όά
ϦϑΝΫλ9
ϑΟʔνϟʔ%
όά
ϦϑΝΫλ:
ʜ
ʜ
Slide 32
Slide 32 text
プロダクトバックログリファイ
ンメント
• プロダクトバックログアイテムに対して、詳細の追加、見
積り、並び替えをする活動
• いつどのようにリファインメントをするかは、スクラム
チームが決定する
• 開発チームは見積りに対して責任を持つ
• プロダクトオーナーがトレードオフの理解や選択などにつ
いて開発チームに影響を及ぼすこともあるが、最終的な見
積りは実際に作業をする人が行う
Slide 33
Slide 33 text
プロダクトバックログ
https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
• プロダクトバックログの項目(p.12)を読んでく
ださい
• プロダクトバックログを作るのは何のためで
すか？ないとどうなりますか？
• 各チームで議論してください
Slide 34
Slide 34 text
イベント1: スプリント
• スクラムの中心はスプリント
• 「完成」した、利用可能な、リリース判断可
能なプロダクトインクリメントを作るための、
1 か月以下のタイムボックス
• スプリントの長さは常に一定
Slide 35
Slide 35 text
イベント2: スプリントプランニング
• スプリントの作業はスプリントプランニングで計画する
• プランニングはスクラムチーム全体の共同作業
• トピック1: スプリントで何ができるか？
• PBL + インクリメント + キャパシティ + ベロシティ -> 選択したPBI
• トピック2: 選択した作業をどのように成し遂げるか？
• 選択したPBI -> スプリントバックログ
• 通常はシステムの設計から始める
Slide 36
Slide 36 text
成果物2: スプリントバックログ
ϑΟʔνϟʔ" λεΫ λεΫ λεΫ λεΫ
λεΫ λεΫ λεΫ λεΫ
• 開発チームがスプリントで行う作業がリアルタイムに
反映される
• 新しい作業が必要になれば、開発チームがスプリント
バックログに作業を追加する
• 計画の要素が不要になれば削除する
• スプリントバックログアイテムのサイズは1日未満を
推奨
• 前回のレトロスペクティブで特定した優先順位の高い
プロセスの改善策を少なくとも1つは含める
Slide 37
Slide 37 text
スプリントバックログ
https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
• スプリントバックログの項目(p.13)を読んでく
ださい
• スプリントバックログを作らずに実装を開始
すると何が起きますか？
• 各チームで議論してください
Slide 38
Slide 38 text
イベント3: デイリースクラム
• 前回のデイリースクラムから行なった作業の検査と今後のスプリント作業の予想をする
ことで、チームのコラボレーションやパフォーマンスを最適化する
• デイリースクラムは、開発チームがスプリントゴールを達成する可能性を最適化する
• たとえ ば、以下のような例を使用する:
• 開発チームがスプリントゴールを達成するために、私が昨日やったことは何か？
• 開発チームがスプリントゴールを達成するために、私が今日やることは何か？
• 私や開発チームがスプリントゴールを達成する上で、障害となる物を目撃したか？
開発チームやチームメンバーは、デイリースクラムの終了直後に集まり、スプリントの残
作業につい て、詳細な議論・適応・再計画を行うこともある。
Slide 39
Slide 39 text
デイリースクラム
• デイリースクラムの項目(p.10)を読んでくださ
い
• デイリースクラムをしないと何が起きます
か？
• 各チームで議論してください
https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
Slide 40
Slide 40 text
成果物3: インクリメント
• これまでのインクリメントの価値と今回のスプリント
で完成したプロダクトバックログアイテムを合わせた
もの
• スプリントの終了時には、新しいインクリメントが
「完成」していなければいけない。つまり、インクリ
メントが動作する状態であり、スクラムチームの「完
成」の定義に合っていることを意味する。
• プロダクトオーナーがリリースを決定する／しないに
かかわらず、インクリメントは常に動作する状態にし
ておかなければいけない
Slide 41
Slide 41 text
インクリメント
https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
• インクリメントの項目(p.14)を読んでください
• スプリント終了時に「完成」したインクリメ
ントを用意するのは何のためですか？インク
リメントが未完成だとどうなりますか？
• 各チームで議論してください
Slide 42
Slide 42 text
イベント4: スプリントレビュー
• スプリントの終了時にインクリメントの検査と、必要であれば
プロダクトバックログの適応を行う
• スクラムチームとステークホルダーがスプリントの成果をレ
ビューする。スプリントの成果とプロダクトバックログの変更
を参考にして、価値を最適化するために次に何ができるかを参
加者全員で話し合う。
• 次にリリースするプロダクトの機能や性能のスケジュール・予
算・可能性・市場をレビューする
• 新たな機会に見合うように、プロダクトバックログを全体的に
調整することもある
Slide 43
Slide 43 text
スプリントレビュー
• スプリントレビューの項目(p.11)を読んでくだ
さい
• スプリントレビューを開催するのは何のため
ですか？なくなるとどうなりますか？
• チーム内で議論してください
https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
Slide 44
Slide 44 text
イベント5: スプリントレトロス
ペクティブ
• スクラムチームの検査と次のスプリントの改善計画を作成する機会
• スプリントレトロスペクティブには、以下の目的がある:
• 人・関係・プロセス・ツールの観点から今回のスプリントを検査する
• うまくいった項目や今後の改善が必要な項目を特定・整理する
• スクラムチームの作業の改善実施計画を作成する
• スクラムマスターは、次のスプリントが効果的で楽しいものになるように、ス
クラムチームにスクラムプロセスフレームワークの範囲内で開発プロセスやプ
ラクティスを改善してもらう
Slide 45
Slide 45 text
スプリントレトロスペクティブ
https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
• スプリントレトロスペクティブの項目(p.12)を
読んでください
• スプリントレトロスペクティブをするのは何
のためですか？なくなるとどうなりますか？
• 各チームで議論してください
Slide 46
Slide 46 text
その他補足
Slide 47
Slide 47 text
学習リソース
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
Slide 48
Slide 48 text
各現場の実装と大規模スクラム
• それぞれの現場はフレームワークをもとに現
場の事情にあわせた実装をしています
• スクラムのフレームワークと完全に一致しな
い部分もあります
• 特にkintone,Garoonは大規模スクラム(LeSS)
の仕組みが入っています
Slide 49
Slide 49 text
エクササイズ
Slide 50
Slide 50 text
こんなときどうする？ #1
• スプリント中にPOに質問したいことが出てきまし
た。どうしますか？
• PBIを開発中に、PBIとは関係ない箇所で不具合を
見つけた。どうしますか？
• リリース後の不具合が多発しています。チームと
して何をすることができますか？
• レトロスペクティブで出た改善アクションは、い
つ・どこで・誰が実施しますか？
Slide 51
Slide 51 text
こんなときどうする？ #2
• スプリントプランニングで計画していた実装方法
が、スプリント中にうまくいかないことがわかり
ました。どうしますか？
• チームがコミットメントした3つのPBIのうち2つ
終わった時に、3つ目に着手してもスプリント内
で終わりそうにないことがわかりました。チーム
としてどうしますか？
• チームがコミットメントしたPBIがスプリント中
にすべて終わりました。チームとしてどうします
か？
Slide 52
Slide 52 text
Reflection
Q&A