初日にプランニングミーティングを行い、直近(2週間等)のタスクを計画
そして、毎日デイリースクラムを実施し、最終日にレトロスペクションミーティングで締めて
スプリントの1サイクルとなる
ミーティングでは、タスク管理システムないしは、
ホワイトボードに張られたタスクやバックログリスト（場合によってはガントチャート）などの
タスクを一覧できるツールを用いる
///プランニングミーティング
プロダクトバックログから優先順位に従って選択したストーリーをタスクにブレークダウン
ミーティング前
1．タスクを決定する
ミーティング時
2．前スプリントのタスク完了を確認する
3．メンバーの予定作業時間を確認する
4．スプリントのゴールを共有する
5．タスクを説明し工数を見積もる
ミーティング後
6．タスクを割り当てる
///デイリースクラム
昨日何をしたか？
今日何をするか？
進捗を妨げている問題は何か？
///レトロスペクションミーティング
何をしたかについて、1人数分から十数分説明する
何ができないか、どのような課題が残っているかに言及する
↓↓↓↓↓↓アジャイルから明確にスクラム
■スクラム
https://qiita.com/gold-kou/items/90ba982a14ca79d843c9
///対話の価値（左が要らないとは言っていない）
プロセスやツール ＜ 個人と対話
包括的なドキュメント ＜ 動くソフトウェア
契約交渉 ＜ 顧客との対話
計画に従う ＜ 変化への対応
透明性：スクラムチームの現状や問題点を見える化すること
検査：見える化により問題点を見つけること
適応：スクラムチームに問題があった場合に、改善策を考えて対処すること
個人はスクラムチームのゴールの達成を確約しなければならない
メンバーは正しいことをする勇気を持ち困難な問題に取り組まなければいけない
全員がスプリントの作業とスクラムチームのゴールに集中しなければいけない
スクラムチームとステークホルダーは仕事や課題とその遂行の様子を公開する
メンバーはお互いを能力のある独立した個人として尊敬しなければいけない
///プロダクトオーナー(PO)
- プロダクトバックログアイテム(PBI)の管理
- リリース計画策定
- 市場調査
- ステークホルダとの対話
- 開発チームとの対話
- 予算管理
- スプリントレビューで"DONEの定義"にしたがって受け入れ判断をする
注意点：POを複数人で実施することも可能だが、その場合は代表者を1人決めておく必要がある。
///スクラムマスター（SM）
- 妨害リストの管理
- 妨害の除去
- POのサポート
- 開発チームのサポート
注意点：チームが自己組織化するために、SMはメンバーに直接的な指示（タスク割り当てなど）や管理（進捗管理など）をしてはいけない。スクラムにはPMは存在しない。
///開発チーム
- 開発、インクリメント（成果物）を完成
- プロダクトバックログの追加
- 妨害リストの追加
注意点：開発チームは自己組織化されており、外部から仕事の進め方やタスクを指示されるようなことがあってはならない。1つの開発チームは3-9人で構成されなければならない。それより少ないと機能横断的でなくなる可能性が高くなるためNG。多すぎると調整が大変になってしまうためNG。多すぎる場合は別のスクラムチームをもう1つ作るべき。開発チーム内で年齢や役職、会社の違いがあったとしても全員フラットな関係でなければならない。開発チームに専門能力の高いメンバーがいて、その分野ではその人に頼りがちだけど、そこで問題が起きたとしてもそれはそのメンバーだけの責任でなく開発メンバー全員の責任であることに注意する。
///ユーザーストーリー形式
「〜として、〜したい。それは、〜だからだ。」を書きます。これは、INVEST(Independent, Negotiable, Valuable, Estimable, Small, Testableの頭文字をとったもの)を満たす必要があります。プロダクトバックログのDoneの定義も定義
///スプリントバックログ
開発チームにより作成される。スプリント期間中での修正、追加、削除も可能である。スプリントバックログの管理を行えるのは開発チームだけである。規模や工数はバラバラで問題ないが、1つのスプリントバックログアイテムの見積もりは1日以下の大きさに分割すること。スプリントバックログアイテムは"未着手"、"着手中"、"完了"などのいずれかのステータスがラベル付けされており、そのステータスが可視化されている必要がある。JIRAでも付箋とホワイトボードによるアナログ方式でもどちらでも問題ない。自己組織化されているので、誰かに割り当てられるものではなく自ら挙手する。設計、コーディング、テストコードの作成だけでなく、結合テストなどの実施、CI環境改良、ノウハウを残すなどもスプリントバックログとして分割するべきである。
///妨害リスト
スクラムチーム内外で、妨害になっていることを優先度順にリスト化したものである。どのロールの人でも追加できるが、妨害リストの管理の責任者はSMである。いつでも追加可能だが、特にデイリースクラムやスプリントレトロスペクティブで課題（妨害）の共有が行われやすい。
///スプリント
1ヶ月以内の固定した開発期間を何度も繰り返す。1週間、2週間、1ヶ月のいずれかが一般的。スプリント期間内に完了しなかったプロダクトバックログアイテムがあったとしても、スプリントを延長してはいけない。スプリントの中止はよっぽどのことが無い限り、行われるべきでないが、もしものときは実行権限を持つのはPOだけである。
///スプリント0
自己紹介、スクラム理論の勉強会（認識合わせ必須）、当面のプロダクトバックログの作成と共有、必要技術スキルの勉強会、開発環境構築などを行うスプリント開始前の準備期間のこと。必要期間はチームにより異なる。
///リリーススプリント
インクリメントの統合テストや通常スプリントで残ったタスクを実施してリリースを行うための特別なスプリント。 原則、このスプリントは存在しません。スプリント毎にリリース可能なものを作成するので、リリーススプリントが無いことが理想だが、そうでない場合に用意される。リリーススプリントはPOがリリース準備が整ったと判断するまで続く。
///イベント
開発チームでイベント以外のミーティングができるだけ行われないようにする。全てのイベントはタイムボックス化されている（何分とか、何時間までとかが決まっている）。もし、タイムボックスを超えてしまった場合、議論をそこで打ち切る必要はないが、タイムボックスを越してしまったという事実は妨害リストに追加したり、スプリントレトロスペクティブで話し合う必要がある。
///スプリントプランニング
第一部は全てのロールが参加する。ただし、第二部はPOは連絡がつく状態であれば参加しなくてもよい。第一部では、ベロシティをもとに今回のスプリントで対応できそうな範囲でプロダクトバックログを開発チームが選択する。（POが選択してはいけない）
プロダクトバックログはリファインメントによってすでに見積もりがされている状態のはずだが、リファインメント後に新規追加されたプロダクトバックログアイテム（つまり見積もりがまだされていないもの）が含まれている場合は、この場でリファインメントを実施する。第二部では、開発チームは選択したプロダクトバックログアイテムをスプリントバックログに分割する。これにより、POとSMにどのようにプロダクトバックログアイテムを消化できるかを伝えられる状態になる。分割したスプリントバックログに時間数を見積もり、その総計が1スプリントでのチームが開発できる時間をオーバーした場合は優先度の低いプロダクトバックログから外していく。逆に余裕がある場合なプロダクトバックログを追加する。POの予想より多すぎたり少なすぎたりする場合は、開発チームとPOは話し合う。開発チームは選択したプロダクトバックログアイテムを完了することに全力を注がなければならないが、完了することを約束するわけでない。なぜならば、見積もり時にはわからなかった技術的に困難な事象が発生することはよくあるからである。無謀な長期の残業は行わない。
///デイリースクラム
- いつ？⇒毎日同じ時間（一般的には朝）
- どこで？⇒どこでもいいがいつも同じ場所
- 誰が？⇒開発メンバー。SMは必要に応じて参加する。POは見学（発言は基本的にNG）してもよい。
- 目的は？⇒開発チームの検査
- どれくらい？⇒最大15分
昨日やったこと、今日やること、あれば課題（妨害）の共有。課題は共有に留めること。管理職の見学は避けたい。なぜならば、共有でなく管理職への報告になりがちで自己組織化が損なわれやすいのと、課題共有がしにくい雰囲気になりやすいからである。もし管理職にエスカレーションするべき課題があるならば、デイリースクラム後に報告すること。
///プロダクトバックログリファインメント
- いつ？⇒スプリント期間中であればいつでも良い。
- 誰が？⇒全てのロール
- 目的は？⇒プロダクトバックログの透明性の獲得
- どれくらい？⇒最大1日(8h)
POはプロダクトバックログの説明（前回からの変更分、追加分、削除分、詳細決定部分、順序変更部分など）を行う。リファインメントの対象は、次のスプリントあるいはさらにその次のスプリントで開発対象となりそうなくらいの範囲となる。優先度低いプロダクトバックログの説明までは行う必要はない。本当に実施するかも不透明だし変更も発生しやすいため。開発チームはプロダクトバックログへの意見（追加アイディアや順序変更や質問など）、新しいプロダクトバックログアイテムの見積もり、必要であれば再見積もりを行う。
///プランニングポーカー
プロダクトバックログの見積もりには"プランニングポーカー"と呼ばれる手法が一般的に使われる。プ開発チーム全員がフィボナッチ数列（0, 0.5, 1, 2, 3, 5, 8, 13,...∞）の値が書かれたカードを持ち、プロダクトバックログアイテムごとに「いっせーのせ！」でカード（見積もり）を提示する。この見積もりは単位のない"相対見積もり"である。見積もりの値が似たような値で均等に分散したとき（例えば5が3人で8が3人の場合）は、悲観的に考えて大きい値（ここでは8）をストーリポイントとして計算したほうがよい。
///スプリントレビュー
- いつ？⇒スプリントの終わり
- 誰が？⇒全てのロールとPOが招待した重要な関係者（ステークホルダーなど）
- 目的は？⇒インクリメントの検査とプロダクトバックログの適応
- どれくらい？⇒最大2時間（スプリント2週間の場合）
開発チームはインクリメントのデモを実施して、質問に答える。また、完了できなかったプロダクトバックログがあれば説明する。開発チームはデモをやることと受け入れに通ることばかり考えがちだが、大切なのはスプリントレビューを通して、よりよいプロダクトを得るための手がかりを見つけることである。デモはそのための手段であって目的ではないことに注意しよう。また、デモの説明スライドは作るべきでない。そこに労力が割かれがちだからだ。POはDONEの定義に従い、インクリメントが受け入れ可能かを判断する。
///スプリントレトロスペクティブ
- いつ？⇒スプリントレビュー後かつ次のスプリントが開始される前
- 誰が？⇒SMと開発チーム。POは参加してもよいが必須でない。
- 目的は？⇒スクラムチームの検査と適応
- どれくらい？⇒最大1.5時間（1スプリント2週間の場合）
スプリントで人・プロセス・ツールの観点から問題がなかったか、もっと成果を出すためにできることがないかを議論し、次回のスプリント以降の改善策を考える。手法として、KPT（Keep, Problem, Tryを出し合うこと）がよく使われる。
///ベロシティ
ベロシティとは、そのスプリントで開発したプロダクトバックログのストーリーポイントの合計である。スクラムチームはベロシティを高めて安定させることを目指す。そもそもストーリーポイントがいい加減な値。フィボナッチ数列の値しかだせないし、開発者は技術的な不安点があるからとりあえず大きな値をしばしば出しがちである。さらに、スプリントの日数は祝日、メンバの休暇などでスプリント毎に異なるものである。
スクラムではテスト専門チームの存在を許していない。スプリントの中で徹底的にバグを発見して潰すべきなのである。
■スクラムガイド Ken Schwaber & Jeff Sutherland
2020-Scrum-Guide-Japanese.pdf (scrumguides.org)
■マネジメント向け アジャイルの利点
https://www.ryuzee.com/contents/blog/13147
■カンバン
ToDo、進捗、ワークフロー整理、振り返り、で活用できれば
カンバンの基本のキ - Qiita
※なおトヨタのカンバン方式は意味自体はJust in timeの意、中で使われていた伝達法もTodoリストと違う、生産と運搬のタグみたいなもの
■JIRA
コンポーネントはプロジェクトを分割（トップダウン）
エピックはストーリーを一定のジャンルでグループ化（ボトムアップ）
タスクはスプリントの期間で終わり作業が内容が分かるタイトルに
ラベルがあれば時間集計できるので作業ラベル