ScrumTraining2020

Transcript

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