アジャイル開発とスクラム
アジャイル開発とは？
短い開発サイクルで成果物とプロセスのカイゼンを繰り返す開発思想
アジャイルの目的
激しく変化するビジネスのニーズに合わせて柔軟に追従した開発を行う
カイゼンとは？
「いまあるものをよりよいもの」にしていくという精神を基にした作業者主体の活動
日本の製造業が発祥
「改善」と「カイゼン」の違い
改善: 問題を解消するため問題発生時に行う
カイゼン: 現状をより良くするために常に行う
アジャイル開発は「カイゼン」を前提にしている
ソフトウェア開発の不確かさについて
IT市場の変化によりソフトウェア開発にはより不確かな要件を求められるように変化した
モノが充足したことによりモノ（物）消費からコト（体験）消費が求められる
ユーザーの反応をプロダクトに素早く反映し、ビジネス価値の向上を継続的に行う必要がある
売り切り型からサブスクリプション型へ需要が変化したことで、ユーザーのニーズに対して継続的にUX（ユーザー体験）の改善を行う必要がある
アジャイルの4つの価値観と12の原則
アジャイル開発のマインドセット、具体的な考え方と行動について以下の2つが宣言されている
「アジャイルソフトウェア開発宣言」: アジャイル開発を行ううえで重視するべき4つのマインドセット
「アジャイルソフトウェアの12の原則」: 「アジャイルソフトウェア開発宣言」のマインドセットを実現するための具体的な考え方と行動
アジャイルソフトウェア開発宣言
1. 対話でのコミュニケーションで良いチームを作る
2. 動くソフトウェアで検証し、プロダクトとプロセスを改善する
3. 顧客との協調が良いプロジェクトを作る
4. 変化を味方にして成果を高める
アジャイルソフトウェアの12の原則
1. 顧客満足を最優先し、価値あるソフトウェアを継続的に提供する
考え方
価値のあるソフトウェアを継続的に提供し、ビジネスゴールの達成の観点で満足してもらう
QCD（品質、コスト、納期）の達成では無く、ビジネスゴールの達成を目指す
ビジネスの実現を最優先に考えてソフトウェアを構築する
開発者は顧客と同じ目線で価値の創出について考える
具体的な行動
ビジネス側、開発者でビジネスゴールについて徹底的に話し合う
ビジネスゴールに向かっているかを常に確認し、修正する
ソフトウェアの要件を顧客の立場で考える
顧客が価値を確認しやすい単位に成果物を分割する
2. 改善に繋がる要求、変更を受け入れて競争力に貢献する
考え方
柔軟に変更を受け入れることで企業の競争力を高める
改善に繋がる要求は新しい価値を見つけた証拠である
開発の初期段階ではソフトウェアに求められる要求が不明瞭で、作るものが不明確になってしまうことを前提に考える
開発後期であっても価値のある要求は柔軟に受け入れる必要がある
具体的な行動
変化を「新しい価値」の発見と捉える
改善に繋がる要求を生み出すことに努める
価値がある変更は積極的に受け入れる
間違いについてもオープンに議論する
よりよいフィードバックを生み出すようなリリースに努める
3. 短い時間間隔でリリースする
考え方
短い時間間隔（2-3週間）でのリリースがビジネスの舵取りを容易にする
リリース間隔が長いと変化したビジネスゴールに追従できない
ビジネスゴールが変化することが想定される場合は仮説検証型で進める
短い間隔でのリリースで顧客からのフィードバックを元にした変更が容易になる（仮説検証型）
具体的な行動
要求は不確実で変化することが前提だと認識する
ビジネス観点で評価できる成果物のみを提供する
リリース間隔はビジネスの観点から決定する
市場からのフィードバックを共有する
4. プロジェクト関係者全員で共通の目標に向かう
考え方
ビジネス側と開発者の共通目標に向かうことで以下のメリットが得られる
リリース~フィードバックまでのサイクルが円滑になる
プロジェクトの変化に追従できる
認識齟齬が起きにくくなる
ビジネスの価値を最大化できる
あるべき姿を共有し、継続した改善が必要である
具体的な行動
一緒の場所で働く
共通目標は日々確認する
双方向のコミュニケーションを図る
共通認識を持つための必要最低限のドキュメントを作成する
5. メンバーを信頼することで意欲を高める
考え方
メンバーが相互にリスペクトし、信頼し合うことでメンバーの意欲が高まる
プロジェクトの成功には意欲の高いメンバーが必要である
具体的な行動
ビジネス側、開発者は互いを信頼する
自ら考え、自らの行動と判断に責任を持つ
顧客の価値創造のために何ができるかを行動の軸にする
6. 直接対話でコミュニケーションする
考え方
直接対話が認識齟齬を防止する最良の方法である
齟齬が発生しても早期に気付くことができる
伝えたい情報の中には正確に表現できない情報も存在する
具体的な行動
正確な情報伝達を行いたい場合は直接対話を行う
正確に表現できない事柄は直接対話で伝達する
双方向の議論を意識する
テキストのみの伝達は対話よりも非効率だと認識する
対話の中で言葉にならない本心を感じ取る
7. 動くソフトウェアで進捗を測る
考え方
動くソフトウェアでの進捗管理が最も正確である
動くソフトウェア以外での進捗では問題に気付けない
報告書では無く、実物で進捗を確認する
具体的な行動
計画通りに進んでいるかでは無く、要求をどれだけ実現できているかで測る
進捗はパーセントでは無く、受入基準の合格/不合格で表現する
小さな単位で開発し、動くソフトウェアを早いタイミングで見せれるようにする
8. 開発ペースを継続的に維持する
考え方
価値あるものを提供するには心身ともにベストな状態を維持することが重要
過負荷な状態では創意工夫、改善の意欲は起きない
過負荷な状態では結果的にトータルパフォーマンスは低下する
行動
機能を小さく分割し、短い期間で価値提供できるようにする
タスクを小さく均一化、優先度の決定を繰り返す
生産性を見える化し、ペースを可視化する
ボトルネックを見つけて改善する
9. 技術を継続的に学び、プロダクトの品質を高める
考え方
技術、設計を学び続けることでプロダクトの品質が高まる
高い技術力が良い設計、高い保守性を生み出す
保守性が低下するとビジネスゴールの変化に追従できなくなる
行動
最新の技術を学び、プロダクトに反映する
可読性をツールで診断する
自動テストで問題を早期発見する
10. 無駄を発見して無くしていく
考え方
価値に直結しない作業、機能を無駄と認識する
常識や慣習にとらわれずに無駄を探す
無駄の削減がコスト削減、生産性向上に貢献する
行動
要求が本当に必要なのかを顧客と一緒に考える
顧客に価値をもたらさない会議、報告を無くす
11. 良いチームが良いプロダクトを生み出す
考え方
良いチームとは自律型である
自律型とは自身の行動に責任を持ち、チーム内で連携して成果を最大化できること
自律型のチームは継続的に改善が行われ、相乗効果で能力以上の成果を発揮できる
具体的な行動
チーム内で目的、目標、ルールを共有
ルールはチームで決める
率先して改善に取り組む
不得意分野にチャンレンジする
作業状況をオープンにする
メンバーの問題はチームの問題だと認識する
12. 定期的に振り返りでやり方を調整する
考え方
定期的な振り返りでやり方を調整することでチームが成長する
定期的な振り返りが失敗の影響を最小限にできる
定期的な振り返りがチーム内での言いにくいことを言えるようになる
具体的な行動
責任の追及では無く、問題の解決に目を向ける
振り返りは短い時間で行う
振り返りのルールはチームで決める
失敗は許容し、改善の対象として認識する
代表的なアジャイル開発の手法
アジャイルな開発を実現する具体的な手法にはいくつかの手法がある
スクラム: 短期間の反復で開発し、継続的にプロダクト、プロセスを改善する
XP（エクストリームプログラミング）: ペアプログラミング、テスト駆動開発、CI/CDなど技術的プラクティスで品質と柔軟性を高める
カンバン: タスクボードで作業の見える化、最適化を行う
アジャイルの基本コンセプト
アジャイルを実践するための3つの基本コンセプト
1. チーム
開発プロセスを通して以下のようなチームへの成長を目指す
プロダクト開発に必要な技術を持ち合わせたチーム（職能横断型チーム）
チーム内で課題を解決していくチーム（自己組織化チーム）
プロダクトに必要なスキルを身につけている
2. インクリメンタル
少しずつ作る
一気に作らずに少しづつ積み上げて作るイメージ
不確実な要求に対する軌道修正をすばやく行える
小さく軌道修正を行うことで手戻りを小さくする
成果物にはプロダクトだけでなくチームの成長も含まれる
3. イテレーティブ
反復的に作る
期間（タイムボックス）を定め、期間単位で繰り返し作っていく
フィードバックを期間毎に反映させて軌道修正を容易にする
期間ごとにリリース可能な状態を目指す
アジャイル開発の特徴
段階的に見積もりを行う
「全体感の見積もり」「タイムボックスごとの見積もり」の2つの見積もりで全体と詳細を段階的に明確にしていく
「見積もりは推測にすぎない」という考えを前提にする
開発開始前の見積もりを開発開始後の実績値を元に補正していくことで正確性の高い見積もりにブラッシュアップしていくイメージ
1. 全体感の見積もり
必要な全機能の完成までに必要なタイムボックス数を見積もることで全体感の見立てを行い、コストや予算を算出する
洗い出す機能群は見積もり開始時点で分かる範囲にとどめる
これまでの開発経験や類似の開発実績を元にした憶測も加味する
2. タイムボックスごとの見積もり
開発開始後のタイムボックス内でタイムボックスで行う作業に対する詳細な見積もりを行う
見積もり対象を直近の作業のみに絞ることで仕様変更が発生した場合に追従しやすくなる
タイムボックスごとに見積もりを繰り返すことでそれまでの実績値を加味したより精度の高い見積もりを行うことができる
計画作りは対象とタイミングで個別に行う
計画作りの対象期間とタイミングで3つのイベントに分けて計画を行う
頻繁に計画作りを行うことで状況の変化に応じて計画の変更を容易にする
頻繁に計画作りを行うことで計画の着地予想の精度を継続的に高める
現時点の状況と把握している情報を元に次の行動（段取り）の決定/変更を行う
1. 大きな計画作り
リリースまでの期間を対象にした計画作り
リリースまでに必要なタイムボックスの数を算出し、リリース時期を予測する
タイムボックスごと or 固定間隔で行う
リリースプランニングと呼ばれる
2. 小さな計画作り
タイムボックスの期間を対象にした計画作り
タイムボックスでの作業対象を決定し、見積もりとタイムボックス完了時の進捗を予測する
タイムボックスごとに行う
スクラムではスプリントプランニングと呼ばれる
3. その日の計画作り
日々の作業を対象にした計画作り
「昨日の作業」「今日の予定」「問題点、懸念点」について共有を行う
共有された情報を元に日々の作業の進捗を予測する
スクラムではデイリースクラム呼ばれる
要件定義、設計は全体と部分で分けて行う
要件やビジネスゴールの不確実性に追従するために、全体の決定タイミングを遅らせれるように全体と部分で分けて要件定義、設計を行います。
1. 全体的な要件定義、設計
開発前に全体をイメージでき、タイムボックス数を見積もれることを目標に行う
詳細な要件の決定や設計は行わない
開発の前段階で行う
2. 部分的な要件定義、設計
タイムボックスでの作業対象に対して完璧にイメージできるレベルで詳細に行う
開発のタイムボックスごとに行う
アジャイル開発の実践プラクティス
アジャイル開発で用いられる実践的なプラクティスについて
テスト駆動開発（TDD）
プロダクトコードよりも先にテストコードを書いておき、テストがパスするようにプロダクトのコードを書いていく開発手法
テスト自動化ツールと組み合わせることで異常を自動で検知できる
テストコードが仕様になるので実装時に仕様に悩むことが減る
開発後の保守性が高まる
継続的インテグレーション（CI/CD）
リリース時のテスト、ビルド等の必要な作業を自動化し、リリースできる状態を保つ仕組み
リリース時の人的ミス、予期しない問題を回避できる
高頻度リリースが可能になりプロダクトの品質を維持できる
ペアプロ、モブプロ、ペアワーク
複数人で1つのPCを使用して開発や問題解決を行うこと
レビューし合っている状態を保つことでのレビュー時間を削減できる
手戻りを最小限に抑えられる
メンバーと協力することで難しい問題もで解決できる
共通体験をすることで効率的に知識の移転ができる
振り返り
1~2週間の短い間隔でプロセスや課題を共有し改善すること
スクラムではスプリントレトロスペクティブと呼ばれる
振り返りで用いられる手法には以下のようなものがある
KPT
ホワイトボードなどにKeep/Problem/Tryで区切った枠内にメンバーそれぞれが以下の項目ごとに付箋に書き出し、チーム内で情報共有を行う。
Keep/Problem/Tryの頭文字 - Keep: 良かったこと、継続すること
Problem: 悪かったこと、改善すること
Try: Problemへの改善/対策
共有されたTryに対してチーム内で投票を行い、次に行う改善策/対策を決める。
YWT
わかったこと（気付き）を元に次の行動を決定し、継続的に改善を行う振り返りのフレームワーク。
以下の項目ごとに振り返り、改善のループを回す。
Y: やったこと
W: わかったこと
T: 次にやること
見える化
プロジェクトの進捗状況を把握しやすくするプラクティス
以下のようなプラクティスがある
カンバン
業務プロセスと進捗状態を1つの流れとして見える化し、誰がどのプロセスを行っているかを把握できるようにするプラクティス
全体の進捗状況を把握しやすくなる
ボトルネック発見が容易になり改善に繋げやすくなる
前後のプロセスを意識した行動を起こしやすくなる
バーンダウンチャート
残タスク数と残り日数を折れ線グラフで見える化するプラクティス
縦軸にタスクの見積もり時間、横軸に作業日を元にして折れ線グラフを作成する
リリースやスプリントなどの見える化する対象によって以下のように呼称が変わる
リリースバーンダウンチャート
スプリントバーンダウンチャート
スクラム
スクラムとは？
アジャイル開発を実現させる具体的な開発手法の一つ
スクラムの特徴
プロダクトに求められる要求を小さい単位で分割する（プロダクトバックログ）
固定した短い時間に区切って作業を進める（スプリント）
進捗状況、問題点、成果をプロジェクト内で共有する（イベント）
問題点や改善点を継続的に改善していく
ロールとは？
スクラムでの開発を行う際の3つの役割
ロールの兼任は可能だが推奨されない
プロダクトオーナー、スクラムマスターの兼任は絶対NG
役割を分割することで問題を把握しやすくなる
役職、肩書とは別にスクラム内で与えられる役割
3つの役割を合わせてスクラムチームと呼ぶ
1. プロダクトオーナー（PO）
プロダクトバックログの管理責任者
プロダクトにつき1人
何のために、何を、どのような順番で作るかを考える人
2. 開発チーム
プロダクトの開発を行うチーム
プロダクトオーナーが実現したいことを作る人たち
3~9人で構成される
プロダクト開発に必要な技術を持ち合わせたチーム（職能横断型チーム）
チーム内で課題を解決していくチーム（自己組織化チーム）
サブチームは作らない
3. スクラムマスター
開発プロセスの円滑化を行いプロダクトオーナー、開発チームを支える支援者
プロダクトオーナー、開発チームがスクラムでの開発をうまく進めるようにする人
管理者では無く、プロジェクト全体のコーチや支援を行う
スクラムの用語
スクラムで使用される用語
タイムボックス
作業を行う固定の時間
スプリント
透明性
プロジェクト内の問題点、課題を共有すること
検査
プロダクト、プロセスに問題が無いか確認すること
適応
プロダクト、プロセスの問題、課題を解消して反映すること
イベント
スクラムの中で行われる会議、振り返り、レビューなど
プロダクトバックログ
プロダクトに求められる要求、要望を抽出してリスト化したもの
プロダクトにつき1つだけ作成する
実現したい順で並び替える
並び順は定期的に見直し、変更は可能
上位の項目は見積り済みの状態にする
責任者でなくてもリストは作成可能
ゴール
スクラムチームが実現する具体的な成果
ミッション
スクラムチームが必ず達成させるべきこと
スプリント
開発を行う固定の期間
1週間から1ヶ月の間で区切る
キャパシティ
スプリント内で実際に作業に使える時間
インクリメント
過去からの成果物と今回のスプリントで完成したプロダクトバックログを合わせたもの
スプリント終了時に正常に動作するソフトウェアになっている必要がある
ステークホルダー
スプリントレビューに必要な利害関係者
インセプションデッキ
開発前に行われるプロダクトのゴールと明らかにすることを知るための会議
ビジネスゴールについての10個の質問にスクラムチーム全員で話し合う
スクラムのルールには含まれていない
エレベーターピッチ
ビジネス上のゴールについて質問を用いて明確にする方法
短時間（30秒~1分）でアイディアやプロダクトを端的に伝える方法
「エレベーターで乗り合わせた人に短時間でプレゼンする」が元になっている
フォーマットを埋めることで端的にまとめる
フォーマットはいくつかの種類がある
フォーマットの例
code:_
我われはなぜここにいるのか
プロジェクトでスクラムチームが達成すべき目標を決める方法
重要だと思われる目標を3つに絞り、その中で死守すべき目標を1つ選択する
完成の定義
プロダクトオーナーと開発チームでの完成についての共通の基準
リスト形式で定義し、各項目を全てパスした場合に完成とみなす
ユーザーストーリー
プロダクトを仕様するユーザーの視点で機能の目的と詳細を記載したもの
プロダクトバックログのリストとしも利用される
相対見積もり
基準の数字を決めて、基準と比較して数字で作業量を見積もる方法
基準にする作業は詳細にイメージできて1週間以内に完了できるものにする
基準より作業量が多ければ大きい数字、作業量が少なければ小さい数字
フィナボッチ数（1,2,3,5,8,13...）で作業量を表現すると誤差の考慮が不要になる
プランニングポーカー（見積もりポーカー）
フィナボッチ数を書かれたカードを使って開発チーム全員で作業量を見積もる方法
チーム全員でのタスクの見積もり方法
タスクを作業時間ではなく規模感で見積もり、全員で同時に提示して決定する
プロダクトバックログの項目ごとに各メンバーが見積もった数字をカードで同時に見せ合う
カードの数字にズレがある場合は意見を交換して、再度カードを出し直すことで見積もりの認識のズレを減らしていく
意見の交換を容易にしてチーム内の認識のズレを減らし、コミュニケーションしやすくするのが目的
ベロシティ
開発チームの平均的な開発スピードを数値で表したもの
スプリント毎に終わらせられる作業量をポイント数で表す
開発チームの過去の実績 or 実際に計測した開発スピードを元に算出する
ポイント数を見積もられたタスクを実際にやってみて計測する方法が最も正確
スプリントプランニング
スプリントで何を作るのか（What）、どのように作るのか（How）について計画を作るイベント
1ヶ月スプリントで約8時間を目安に行う
スプリントゴール
スプリントの目標をまとめたもの
スプリントで行う作業をイメージしやすくするのが目的
スプリントバックログ
_ スプリント内で行う作業
開発チームの作業計画
プロダクトバックログリファインメントでプロダクトバックログから選択する
作業タスクは1日以内で終わるように分割する
デイリースクラム（朝会）
スプリント中に行われる開発チームのための情報共有のためのイベント
毎日同じ時間、同じ場所で行われる
15分のタイムボックスで行い、延長しない
「昨日の作業」「今日の予定」「問題点、懸念点」についてチームメンバーに共有する
プロダクトバックログリファインメント（リファインメント）
スプリントで行う作業について以下の作業を行い詳細を明らかにしていく作業
作業の疑問点の解消
成果物の受入基準の明確化
作業タスクの分割
作業タスクの見積もり
スプリントの10%以内の時間で行う
スプリントレビュー
スプリントで完成したプロダクトのデモを行い、フィードバックを引き出すイベント
スプリントの最後に行われるスプリントの成果をレビューする
プロダクトオーナーが主催
スプリントの成果物を関係者でレビューし、フィードバックを得る機会
スプリントレトロスペクティブ
終了したスプリントのプロセスについて検査、改善するイベント
スプリントの最後に行われる
スプリント毎にプロセスの改善を行うことが目的
1ヶ月スプリントで約3時間を目安に行う
タスクボード
スプリントバックログを進行状況（TODO/DOING/DONE等）によって可視化するツール
スクラム開発の流れ
スプリント開始前に事前準備を行い、その後はスプリントを繰り返しスプリント毎にインクリメントを作成することで開発を進める
スプリント前（事前準備）
スクラムチーム全員でスプリントの為の準備として以下を行う
1. インセプションデッキ
2. 完成の定義の作成
3. プロダクトバックログの作成
4. プロダクトバックログの並び替え
5. バックログアイテムの見積もり
6. ベロシティの予測
7. リリース計画の作成
1. インセプションデッキ
やること: プロダクトのゴール、スクラムチームのミッションについて話し合う
エレベーターピッチ、「我われはなぜここにいるのか」を活用する
話し合いで決まったことについてスライドを作成し、見える位置に張り出す
大事なこと:
スクラムチーム全員がプロダクトについてのゴール、疑問点について話し合う場だと意識する
一方的な説明を行う/受ける場では無い
2. 完成の定義の作成
やること: プロダクトが完成しているかどうかを判断する基準を決める
大事なこと:
完成についてのスクラムチーム内の共通の基準を決めることで完成についての認識齟齬を防止する
3. プロダクトバックログの作成
やること: 実現したいこと、プロダクトのゴールを元に要求、要望を抽出してリスト化する
大事なこと:
スクラムチーム全員でプロダクトバックログの項目を書き出すことで漏れを防ぐ
期限や制約を考慮せずに項目を書き出すことで小さな気付きも書き出せる
スクラムチームがプロダクトバックログを作成することでプロダクトバックログへの理解が深まる
100%の完成度のプロダクトバックログを目指すのでは無く、スプリント開始後に都度修正して完成度を高めていくことを前提にする
4. プロダクトバックログの並び替え
やること: プロダクトバックログの項目の並び替え
項目を優先度ごとにグループに分け、優先度グループごとに並び替えを行う
開発を優位に進めるための項目は優先度のグループとは別のグループとして扱い、並び替えを行う
優先度のグループと開発を優位に進めるためのグループを1つにまとめて全体の優先度を確認する
プロダクトオーナーは優先度の最終決定を行う
大事なこと:
スクラムチームが順序づけを行うことでチーム自体が納得できる見通しを立てれる
開発を優位に進めるための項目を別グループとして考えることでスムーズな流れの優先度を付けれる
5. プロダクトバックログの項目の見積もり
やること: プロダクトバックログの各項目ごとに作業量で見積もる
相対見積もり、 プランニングポーカーを活用する
大事なこと:
見積もりにズレが発生することを前提に考える（見積もりは憶測に過ぎない）
憶測である見積もりに時間を掛けることは無駄な時間だと意識する
6. ベロシティの予測
やること:
短い期間で見積もり済みのプロダクトバックログの項目をいくつかやってみてベロシティを計測する
開発チームに変更が無い場合は過去の実績からベロシティを算出する
大事なこと:
ベロシティは実際に計測したものが最も正確
期限に合わせてベロシティを決めるのはNG
7. リリース計画の作成
やること:
スプリントからリリースまでの計画を作成する
休暇やイベントをカレンダーに書き込んで見える化する
大事なこと:
リリース計画にズレが発生することを前提に考える（見積もりと同様に憶測に過ぎない）
リリース計画はスプリント開始後も見直し続ける
プロダクトバックログで伝わらない全体のスケジュール感を補うイメージ
スプリント開始後（繰り返す1サイクル）
スプリント開始後は以下のイベントと作業を行いながらインクリメントの開発を行う
1. スプリントプランニング
2. デイリースクラム（毎日）
3. バックログリファインメント（スプリント中に随時）
4. スプリントレビュー（成果の確認・フィードバック）
5. スプリントレトロスペクティブ（改善点の振り返り）
→ 次のスプリントへ
1. スプリントプランニング
いつ: スプリント開始直後（スプリントごと）
やること: スプリントについて以下の計画を立てる
このスプリントで何ができるか？（What）
スプリントゴールの設定
デモ手順の決定
受入基準の決定
スプリントゴールを達成するためにスプリントで着手するプロダクトバックログを選択する
ベロシティを元にしてスプリント内で着手するプロダクトバックログの量を決定する
どのように達成するのか？（How）
スプリントで着手するプロダクトバックログに対して以下を行う
作業タスクに分割する
作業タスクごとに見積り、プロダクトバックログの見積もりに反映する（詳細見積もり）
詳細見積もりを元にプロダクトバックログがスプリントで達成可能かどうかの判断と調整を行う
詳細見積もり、作業タスクからスプリントバックログを作成する
大事なこと:
開発チームが「確実に達成できる」とイメージできる具体的な計画が必要
タスクの単位は1日以下のサイズにして進捗を測れるようにする
スプリント開始前に疑問点、不安点が無い状態にしておく
期日を守るために計画を立てるのでは無く、スプリントゴールを達成するための確実な計画を立てることを意識する
2. デイリースクラム
いつ: 毎日
やること: スプリントゴールを達成できるのか検査する
「昨日やったこと」「今日やること」「困っていること」についてメンバーがそれぞれ話していく
タスクボードで進捗確認（任意）
バーンダウンチャートで進捗確認（任意）
大事なこと:
15分という短時間で行うことで集中して検査を行う
進捗報告が目的では無く、問題を発見することが目的
発見した問題の解決はデイリースクラム内で行わずに、デイリースクラム後に必要な人だけで個別に話合う
3. バックログリファインメント
いつ: スプリント中に随時
やること: プロダクトバックログの項目のメンテナンス
優先順位の確認/調整
プロダクトバックログの項目の分割
受け入れ条件の明確化
分割したタスクの見積もり
大事なこと:
開発チームが参加することで技術的な抜け漏れを防止できる
開発チームのプロダクトバックログへの理解が深まる、認識齟齬の防止になる
4. スプリントレビュー
いつ: スプリントの最後
何を: スプリントで完成したプロダクトのデモを行い、フィードバックを得る
プロダクトバックログの項目内での完成/未完成の項目を説明
この後の見通しについて説明
場合によってはステークホルダーにも参加してもらう
大事なこと:
動くプロダクトのデモを行うことで本当に期待通りにプロダクトが完成しているのか判断できる（プロダクトを資料やスクショで代用するのはNG）
必要に応じてステークホルダーに参加してもらうことでチーム外からのフィードバックを得られる
5. スプリントレトロスペクティブ
いつ: スプリントの最後
やること:
スプリントのプロセスの検査し、改善点を洗い出す
ベロシティの再算出し、見積もりに反映する
改善点、フィードバックを元に次のスプリントでの改善策を決める
大事なこと:
スプリントを継続的に改善していく為のプロセスのフィードバックを集めるイメージ
スプリント毎に改善を繰り返すことで継続的にプロセスを改善できる
ベロシティを再算出することでベロシティ、見積もりの精度を改善できる
リリーススプリントについて
通常のスプリント後にリリース作業をまとめて行うスプリント
リリース時のトラブルに対処するためのバッファを設けるイメージ
リリーススプリントを設けずに通常のスプリントでリリースまで行うのが理想
2、3スプリントでのリリース完了を目安にする
参考書籍/記事
書籍:
いちばんやさしいアジャイル開発の教本
SCRUM BOOT CAMP
URL: