■ はじめに
スクラム（Scrum）に勉強する。徐々に書き足していく。 以下が非常にわかりやすかった
https://www.atmarkit.co.jp/ait/articles/1208/07/news128.html
目次
【１】スクラムとは？ 【２】スクラムの理論 １）スクラムの3本柱 ２）スクラムの5つの価値基準 【３】スクラム チーム（Scrum Team） 【４】スクラム イベント 【５】バックログ 【６】個人的感想 １）いいなーっと感じた点
【１】スクラム (Scrum) とは？
* チームで仕事の進めるための枠組み => 別に、ソフトウェア開発だけのものではない * 正確には、以下。
https://www.scrumguides.org/download.html
のスクラムガイドの日本語訳より抜粋。 ~~~~~~~~~~~~~~~ 複雑な問題に対応する適応型のソリューションを通じて、 ⼈々、チーム、組織が価値を⽣み出すための 軽量級フレームワークである 簡単に⾔えば、スクラムとは次の環境を促進するために スクラムマスターを必要とするものである 1. プロダクトオーナーは、複雑な問題に対応するための作業を プロダクトバックログに並べる 2. スクラムチームは、スプリントで選択した作業を 価値のインクリメントに変える 3. スクラムチームとステークホルダーは、結果を検査して、 次のスプリントに向けて調整する 4. 繰り返す ~~~~~~~~~~~~~~~ ネット上で「スクラム いらない」ってみるが、この定義で言うと それって、もうスクラムじゃないんじゃないの？って思った、、、 （まー、別に、プロジェクトが円滑に進めば、それでいいけど）
動画
* 取っ掛かりとして、ざっくり以下の動画で学ぶのもいいかも。
https://www.youtube.com/watch?v=5JO3qwnYtjw
* JIRA のScrumに関する動画。
https://www.atlassian.com/ja/agile/scrum
【２】スクラムの理論
１）スクラムの3本柱 ２）スクラムの5つの価値基準
１）スクラムの3本柱
1) 透明性 (Transparency)
* 現在の状況 / 進捗 / 問題点 を常にオープン(見える化)しておく => 開発者全員が共通認識を持って開発が進められる
2) 検査 (Inspection)
* 定期的に、進捗状況 / 成果物 / 仕事の進め方に 問題がないかを確認する => 「1) 透明性」により、見える化したことによりできること
3) 適応 (Adaptation)
* 問題があったり、よりいい方法がある場合、 変化を受け入れ、やり方そのものを変えるなど 臨機応変に適応していく => 「2) 検査」で見つけた問題に対して、改善策を考え、 「3) 適応」していく
２）スクラムの5つの価値基準
https://www.scrumguides.org/download.html
のスクラムガイドの日本語訳より抜粋。
1) 確約（Commitment）
スクラムチームは、ゴールを達成し、 お互いにサポートすることを確約（Commitment）する
2) 集中（Focus）
スクラムチームは、ゴールに向けて可能な限り 進捗できるように、スプリントの作業に集中（Focus）する。
3) 公開（Openness）
スクラムチームとステークホルダーは、 作業や課題を公開（Openness）する。
4) 尊敬（Respect）
スクラムチームのメンバーは、 お互いに能⼒のある独⽴した個⼈として尊敬（Respect）し、 ⼀緒に働く⼈たちからも同じように尊敬（Respect）される。
5) 勇気（Courage）
スクラムチームのメンバーは、 正しいことをする勇気（Courage）や 困難な問題に取り組む勇気（Courage）を持つ。
【３】スクラム チーム（Scrum Team）
* 以下の関連記事を参照のこと。
https://dk521123.hatenablog.com/entry/2021/02/17/000000
【４】スクラム・イベント
* 以下の関連記事を参照のこと。
https://dk521123.hatenablog.com/entry/2021/02/19/000000
【５】バックログ
* 以下の関連記事を参照のこと。
https://dk521123.hatenablog.com/entry/2021/02/18/000000
【６】個人的感想
１）いいなーっと感じた点
１）レトロスペクティブ (振り返り)で、反省会できること
=> これって中々できない
=> 次に活かすという目的であるなら、
例えば、プロジェクト完了後やっても、
終わってるから気持ち的にも気が抜けてるし、
メンバーがそのまま残るとは限らないので
効果的はないと思う
=> そもそも、ほとんどのプロジェクトで
（やったほうがいいと思いつつも）やらない
参考文献
https://qiita.com/gold-kou/items/90ba982a14ca79d843c9
https://codezine.jp/article/detail/12296
https://techplay.jp/column/679
https://geechs-job.com/tips/details/30
関連記事
スクラム開発 ～ 基本編 / チーム ～
https://dk521123.hatenablog.com/entry/2021/02/17/000000
スクラム開発 ～ 基本編 / イベント ～
https://dk521123.hatenablog.com/entry/2021/02/19/000000
スクラム開発 ～ 基本編 / 振り返り ～
https://dk521123.hatenablog.com/entry/2023/03/23/000000
スクラム開発 ～ 基本編 / バックログ ～
https://dk521123.hatenablog.com/entry/2021/02/18/000000
スクラム開発 ～ 見積もり ～
https://dk521123.hatenablog.com/entry/2023/02/04/011603
スクラム開発 ～ ワーキングアグリーメント ～
https://dk521123.hatenablog.com/entry/2023/01/13/222626
スクラム開発 ～ インセプションデッキ ～
https://dk521123.hatenablog.com/entry/2023/01/23/162537
LeSS ～ 基本編 / イベント ～
https://dk521123.hatenablog.com/entry/2023/01/30/235744
LeSS ～ 基本編 / チーム ～
https://dk521123.hatenablog.com/entry/2023/02/01/164201
Scrum@Scale ～ 入門編 ～
https://dk521123.hatenablog.com/entry/2023/02/08/000727
アジャイル開発のスケーリング方法
https://dk521123.hatenablog.com/entry/2023/02/03/130808
