hachimaki37/20240527-scrum

LT発表の資料です。
認定スクラムマスターを取得しました。ということで、早速社内の勉強会でスクラムについて発表しました。

Transcript

1. 勉強会/スクラム 2024/5/27
2. はじめに - 5/16~17日にRegistered Scrum Masterを受講してきました - 本日の勉強会の目的は、新たな気づきを得る機会としたいです。スクラムに ついての気づきをみなさんでたくさん共有し、ぜひ個人やチームの改善に活 かしてほしいです - 本日の勉強会の内容は、スクラムのポイントを抑えつつ、当日に行った一部 のワークとディスカッションをみなさんに体験頂こうと思います - 最後に5分くらいスクラムについてのお悩みや質問タイムを設けようと思いま す（取れなかったらすみません。。）
3. 認定スクラムマスターが伝える 体験で学ぶ スクラムのあれこれ
4. アジェンダ - アイスブレイク：5分（~17:10まで） - 本日伝えたいことをサクッと：5分（~17:15まで） - スクラムのポイントは、都度説明を加えていきます - ワーク①個人：5分（~17:20まで） - ワーク②サイコロゲーム：15分（~17:35まで） - ワーク③飛行機ゲーム：20分（~17:55まで） - お悩み・質問タイム：5分（~18:00まで） - 収まりきらない質問は、slackに投稿いただければ別途回答します
5. ※注記 スクラム用語である「受け入れ条件」という言葉が、時折出てきます。「受け入れ条 件」とは、「完了の定義」を指しています。 つまり、「受け入れ条件」を満たすことで、その作業を完了したとみなします。
6. アジェンダ - アイスブレイク：10分 - ワーキングアグリーメント - スクラムチームを作る
7. ワーキングアグリーメント
8. ワーキングアグリーメント 本日のワーキングアグリーメント（= 共通の価値観）を以下に設定します - 楽しみながら学んでください - 積極的にワークに参加してください - 得た知見や学びをみなさんに共有してください - 時間を厳守してください この4つに賛同頂ける方は挙手をお願いします
9. スクラムでチームを作る方法
10. スクラムチームの基本原則 - 機能横断チーム（= 作業を完了させるために必要な全てのスキルをチームで 有している）であること - 開発者+SM+PO = スクラムチーム。それぞれの役割の責任を果たしつつ、 互いに協力してスクラムチームのゴールを達成すること - スクラムチームが最小単位である。サブチームは存在しないこと - スクラムチームの特徴は、自己組織的（最善の案を自分たちで決定する）・ 機能横断的（作業を成し遂げるためのスキルを全て持っている）チームであ ること
11. 明確な責任を持つ3つの役割 = スクラムチーム - プロダクトオーナーは、なぜ(Why)と何を(What)に責任を持つ - プロダクトやチームの存在意義、魅力的なプロダクトビジョンの策定、顧 客へ価値を届けること　など - スクラムマスターは、プロセスに責任を持つ - 開発者、PO、組織のパフォーマンスを向上させる - スクラムイベントを効果的に繰り返すファシリテート - 作業の見える化、チームや組織のゴールを達成させる - 障害物を取り除くためにプロセスを改善する　など - 開発者は、どのように(How)に責任を持つ - POが決めたwhatをどのようにインクリメントするか - スプリントの作業計画、スプリントゴールを達成するために毎日の作業 計画を状況に応じて適応させる - 完了の定義を忠実に守ることで品質を作り込む　など
12. 明確な責任を持つ3つの役割 = スクラムチーム - プロダクトオーナーは、なぜ(Why)と何を(What)に責任を持つ - プロダクトやチームの存在意義、魅力的なプロダクトビジョンの策定、顧 客へ価値を届けること　など - スクラムマスターは、プロセスに責任を持つ - ボトルネックを特定して、障害物を取り除きプロセスを改善する - ↑によって、開発者、PO、組織のパフォーマンスを向上させる - スクラムイベントを効果的に繰り返すファシリテート - 作業の見える化、チームや組織のゴールを達成させる　など - 開発者は、どのように(How)に責任を持つ - POが決めたwhatをどのようにインクリメントするか - スプリントの作業計画、スプリントゴールを達成するために毎日の作業 計画を状況に応じて適応させる - 完了の定義を忠実に守ることで品質を作り込む　など
13. 明確な責任を持つ3つの役割 = スクラムチーム - プロダクトオーナーは、なぜ(Why)と何を(What)に責任を持つ - プロダクトやチームの存在意義、魅力的なプロダクトビジョンの策定、顧 客へ価値を届けること　など - スクラムマスターは、プロセスに責任を持つ - 開発者、PO、組織のパフォーマンスを向上させる - スクラムイベントを効果的に繰り返すファシリテート - 作業の見える化、チームや組織のゴールを達成させる - 障害物を取り除くためにプロセスを改善する　など - 開発者は、どのように(How)に責任を持つ - POが決めたWhatをどのようにインクリメントするか - スプリントの作業計画、スプリントゴールを達成するために毎日の作業 計画を状況に応じて適応させる - 完了の定義を忠実に守ることで品質を作り込む　など
14. チームに分かれる 今回の勉強会では、以下のルールで2つのスクラムチームを作ります
15. チームに分かれる 今回の勉強会では、以下のルールで2つのスクラムチームを作ります - みなさん主導で、スクラムの経験年数順に一列に並ぶ - スクラムマスターを中心に、極力プロダクトのチームメンバーが固まらない様 にチームを構成する
16. チームに分かれる 受け入れ条件： - 全員がチームに入り、テーブルに座ること - チームでPOを1人選ぶこと（その他のメンバーは複数の開発者になる） - チーム名が決まること（なんでもOK） - POの名前とチーム名をホワイトボードに記載すること POの役割： - ワークでの優先順位の意思決定を担う - ディスカッションの結果を全体に発表し、勉強会の学びを高めることに貢献す る
17. では、早速ワークスタートです！ 5分（~17:10まで）
18. チームに分かれる 今回の勉強会では、以下のルールで2つのスクラムチームを作ります - みなさん主導で、スクラムの経験年数順に一列に並ぶ - スクラムマスターを中心に、極力プロダクトのチームメンバーが固まらない様 にチームを構成する
19. チームに分かれる 受け入れ条件： - 全員がチームに入り、テーブルに座ること - チームでPOを1人選ぶこと（その他のメンバーは複数の開発者になる） - チーム名が決まること（なんでもOK） - POの名前とチーム名をホワイトボードに記載すること POの役割： - ワークでの優先順位の意思決定を担う - ディスカッションの結果を全体に発表し、クラス全体の学びを高めることに貢 献する
20. アジェンダ - 本日伝えたいことをサクッと：5分（~17:15まで）
21. 本日伝えたいこと - 色々伝えたいことはあるのですが、これだけは覚えて頂きたいことにフォーカ スしてお伝えます - あとは、質問してください。全力でお答えします
22. スクラムの仕組み 5つのスクラムイベントから構成されている
23. スクラムのシンプルなルール スクラムのルールは、3-5-3が重要です
24. スクラムは価値主導の文化を作る - 価値基準 - OPENNESS　RESPECT　COURAGE　FOCUS　COMMITMENT 　　「公開」　「尊敬」　　「勇気」　「集中」　　　「確約」 - 経験的プロセスによる三本の柱 - 透明性：見える化、進捗がチームでわかること - 検査：フォードバックから学ぶこと - 適応：検査を次のサイクルに活かすこと この価値基準と三本の柱が下支えすることで、スクラムの成功に繋がる ※重要です
25. なぜ、スクラムを使うのか - 従来のウォーターフォール開発のプロジェクト成功率の調査によると、成功 率: 13%、遅延、予算超過、顧客不満: 59%、失敗: 28%の結果となった - プロジェクト中に要求が変化する可能性は平均して65%ある つまり、プロセスには予測できない変化（複雑、不確実）が起きる。計画からぶれ ないことを前提としたウォーターフォール開発には、これらの課題があった
26. なぜ、スクラムを使うのか - 経験的プロセス - 経験した結果を検査し、そこから学んだことを次のサイクルの計画に適 応させ、変更を加えていく - 検査と適応を通じて成功するためには、作業のプロセスを完全に透明 化する必要がある スクラムは、一つひとつの機能を短いサイクルで完了させ、繰り返しながらインク リメントを作る開発手法。経験的プロセスに基づくことで、前述の課題を解消でき るのではないか。
27. スクラムとは結局何か？ - リーン生産するため - 無駄を省き、問題を取り除くことでより価値を早く届ける - アジャイルマニフェスト（価値観を明文化）を実現するため - 「個人との対話を」「動くプロダクトを」「顧客との協調を」「変化への対応 を」 - 顧客と協調することで、より価値の高いものをチームで届ける リーン生産とアジャイルマニフェストからなる軽量なフレームワークで、デリバリー （価値を届ける）のフレームワークである（問題を明るみに出すフレームワークとも 言われる）
28. アジェンダ - ワーク①個人：5分（~17:20まで）
29. ワーク①個人 - 紙とペンを一人ずつ用意します - やること - 1~10, a~j, 一~十を紙に書きます - これをプロセスが異なるパターンで2回行います - 2回とも書き始めと書き終わりでタイムを測って手元でメモしてください
30. ワーク①個人 - 1回目 - A: 行ごと（横）に、1~10, a~j, 一~十を書いてください - 2回目 - B: 列ごと（縦）に、1~10, a~j, 一~十を書いてください 例）1回目：　　　例）2回目： →　→　→　　　　1　a　一　 1　a　一　　　　↓　↓　↓ 　　　　　　　　　2　b　二 →　→　→　　　↓　↓　↓ 2　b　二
31. 計測が終わったら、以下計算をしてください A - B = C C / A = D D * 100 = D% では、個人ワークスタートです！ 5分（~17:20まで）
32. この式でわかることは、 Aプロセスは、BプロセスよりもD%の無駄がある どのくらいの無駄がありましたか？
33. アジェンダ - ワーク②サイコロゲーム：15分（~17:35まで）
34. ワーク②サイコロゲーム：7分間 次は、スクラムチームでゲームを行います - 受け入れ条件： - POが、ラウンド1,2,3の実施結果をホワイトボードに記載すること
35. ワーク②サイコロゲーム：7分間
36. ワークスタートです！7分（~17:42まで） - 受け入れ条件： - POが、ラウンド1,2,3の実施結果をホワイトボードに記載すること
37. ワーク②サイコロゲーム：7分間
38. ふりかえり：5分 - 質問 - PO：受け取った価値は、ラウンド1,2,3で同じだったでしょうか？異なっ たでしょうか？ - チームメンバー：行った作業の労力は、ラウンド1,2,3で同じだったでしょ うか？異なったでしょうか？ - ディスカッション - ラウンド1,2,3段々と速くなった要因はなんでしょうか？ - スクラムに当てはめて、スクプリントバックログの作業を終わらせるため には、何をすべきでしょうか？ - ディスカッションした内容を全体に共有してみましょう
39. ワーク①と②のまとめ 同じ作業をする場合でも、無駄を省き、問題を取り除くことで、より価値を早く届け ることができるということです。 つまり、スクラムチームのメンバーとして、より価値の高いものを早く届けるためで きること、それはチームや個人の障害を取り除き、プロセスやフローの改善と最適 化を図ることです
40. Tips：スクラムパターン - 安定した（かつ専任の）チーム - 専任チームの生産性は2倍に達する - チームが複数PJを兼任するとスピードが遅くなる - 安定した（かつ少人数の）チーム - 遅れたPJに人を追加するとさらに遅れる - ブルックスの法則：9人を越えると遅延が発生する - スクラムチームは、3~7人が効率が良い - スウォーミング - チームレベルでマルチタスクを回避すると、プロセス効率が劇的に向上 する - コンテキストスイッチのムダを省く - プロジェクトに優先順位をつける
41. アジェンダ - ワーク③飛行機ゲーム：20分（~17:55まで）
42. スクラムによるプロダクト開発
43. スクラムによるプロダクト開発
44. スクラムによるプロダクト開発 ※3回のスプリントを行います※ 2 目安：
45. スクラムによるプロダクト開発
46. スクラムによるプロダクト開発 ※3回のスプリントを行います※ 2 目安：
47. スクラムによるプロダクト開発 - 3分間測ります - 3分間には、以下が含まれます - 計画 - 制作 - テスト - ホワイトボードへの記載 Are you ready? では、3分間スタートです！
48. スクラムによるプロダクト開発 ※3回のスプリントを行います※ 目安：
49. スクラムによるプロダクト開発 ※もう2回のスプリントを行います※ 2 目安：
50. スクラムによるプロダクト開発 - 3分間測ります - 3分間には、以下が含まれます - 計画 - 制作 - テスト - ホワイトボードへの記載 Are you ready? では、3分間スタートです！
51. チーム間で情報を共有してみよう：2分 実は争ってはおりません。みんさんは会社全体を代表するチームです - 開発者1名ずつ： - どのようにプロセスを改善したか？ - 作業の流れは？ - 作業時間の削除は？ - 無駄をどうやって省く？ - PO1名ずつ： - プロダクトをどのように改善したのか？ - 飛ぶ折り方は？ - 飛ばし方は？
52. スクラムによるプロダクト開発 ※最後のスプリントです※ 2 目安：
53. ふりかえり：3分 ディスカッションした内容を共有してみましょう
54. 当日にふりかえった内容 - スプリントごとにゴールを作った方がよかった（1,2,3スプリントごとにスプリン トゴールを設定した方がよかった） - 成功パターンを1スプリント目から目指さなくてもよかった - WIPを作り続けてしまった。それはコストだよね。つまり、改善していく必要が あるよね - POは、優先順位や意思決定を行い、チームを成功に導くべきだった - 別チームから早く成功事例を聞けばよかった - 作業プロセスが、なあなあで共通認識が取れていなかった　など
55. スクラムイベントの各種目的 - スプリントレトロスペクティブ：スプリントの1週間単位に45分以下 - 作業の品質と有効性を高めるためにプロセスを検査する - もっとよくなるために次のスプリントで試してみる1つ以上の改善を特定 する。スクラムにおける最も重要なイベント - スプリントプランニング：スプリントの1週間単位に2時間以下 - スプリントゴールとスプリントバックログを作成する - スプリントバックログ内のPBIは、受け入れ条件が明確であること - スプリントゴールは、スプリント内で現実的に達成可能であること
56. スクラムイベントの各種目的 - デイリースクラム：15分以下 - スクラムチームがスプリントゴールの達成に集中できるようにする - 開発者は、スプリントゴールの達成に向けた進捗状況を検査し、必要に 応じてスプリントバックログを調整および再計画する - 進捗を議論し、障害物を特定する。進捗共有だけの場ではない - スプリントレビュー：スプリントの1週間単位に1時間以下 - プロダクトのインクリメントをステークホルダーにデモし、プロダクトバック ログに適応できるフィードバックを求める - ユーザーやステークホルダーの反応とプロダクトのフィードバックを収集 することが重要な成果
57. スクラムイベントの各種目的 - バックログリファインメント：スプリントの10%までを推奨 - スプリントバックログを作成することができる準備完了（= 受け入れ条件 が明確）のPBIを1~3スプリント分を用意する - 着手するPBIのコンテキストを明確にする - 完了できるサイズに分割し、必要に応じて優先順位を並び替える - 各PBIを完了するために必要な労力を見積もる - プロダクトバックログ：イベントではないが少し説明します - スクラムチームによって成し遂げたい仕事（PBI）の集まりで、ビジネス 価値の順番に並べられている - 誰でも、いつでも、どんなものでもプロダクトバックログに追加できる。た だし、優先順位を最終決定するのはPOのみ
58. ワーク③のまとめ - 作業を細かく分担することで、リードタイムを短くする - プロダクト開発の高速化は、要因追加よりも、プロセスの改善で達成できるこ とが多い - そのためには、何が障害となっているのかボトルネックを特定して、障害を取 り除く必要がある - 局所最適化ではなく、全体最適化を スクラムチームは、フロー効率を改善し、早く顧客に価値を届けることが重要
59. Tips：スクラムパターン - 割り込みのパターン - スクラムチームのメンバーとして、割り込みに対する計画が必要 - 予期せね事態への対処 - 事前に計画ができれば、43%高速化できる - ハウスキーピング - スクラムチームのメンバーとしてチームをリーンにする必要がある - そうすれば、プロセス効率が25%以上になる - 欠陥のないプロダクトを作る - 対応できるならスプリント内で欠陥を直す - バグ対応を遅らせない
60. アジェンダ - お悩み・質問タイム：5分（~18:00まで） - 時間に収まりきらない質問は、slackに投稿いただければ別途回答しま す
61. 最後に スクラムチームにできることは、プロセスやフローの改善と最適化を図り、顧客と 協調しながらより価値の高いアウトカムやアウトプットを早くユーザー・顧客にデリ バリー（価値を届ける）していくこと。 そんなチーム・エンジニア組織に我々がなっていくことで、テクノロジーを通して、 進化の中心を生み出していけるようになっていくのではないでしょうか。
62. Tips：スクラムパターン - 幸福指数：幸せだとパフォーマンスが向上する - 人間のモチベーションは、従来型の外発的要因（お金、権力、地位）と 同様に、内発的要因（目的、感情、思い）でも自然と向上する - 幸福度が高いスクラムチームは、スプリントごとに5~10%ベロシティが 向上する - チームの幸福度が急に低下、そのまま下がり続ける傾向があると、ベ ロシティも次のスプリント、あるいは、それ以降のスプリントで下がること が多い - 幸福度の兆候に早期に対応すると問題を避けられる
63. おしまい ありがとうございました！