| メリット | 外部環境の変化等に伴う仕様変更への融通が利きやすい |
| 各スプリントで都度動かす所まで実施するため、上流工程のミスによる手戻りが小さい | |
| 開発途中にプロセスを改善できる | |
| デメリット | スケジュール管理がしづらい。 |
| 一貫性を確保した開発ができずに、方向がぶれ易くなる。結果、当初の目的を果たせなくなる可能性がある。 | |
| スプリントイベントへの参加等のオーバーヘッドは大きい |
| 三本柱 | 透明性 |
| 検査 | |
| 適応 | |
| 価値基準 | Commitment |
| Focus | |
| Openness | |
| Respect | |
| Courage |
| プロダクトオーナー(PO) 1人 | ・製品開発の全責任を持つ人で、エンドユーザと開発チームの仲介人。 ・ステークホルダーへの調整を行う。 ・製品企画・エンドユーザの意見吸い上げやリリース方法等を検討する。 ・開発チームに製品作成を依頼し、完成したものを確認する。 ・単一障害点になりやすいので、プロダクトマネージャーが別にいてプロダクト全体の調整管理を行い、POがスクラムチームとの調整を行うといった棲み分けをするケースもある。 |
| スクラムマスター(SM) 1人 | ・スクラムがうまく回るように支援する人。チームが自己管理できるようにコーチングする。 ・技術的な課題等、多様な障害(Impediment)を取り除くべくサポートする。 ・立ち位置は支援者であり、実際にプロジェクトを仕切るプロジェクトマネージャではない。 ボスではなく、真のリーダーという表現をよくする。 ・プロジェクト立ち上げ時の役割が非常に大きく、チームが成熟していくにつれて役割は小さくなっていく(PO・開発チームが自己管理できるようにする)。 ・タイムボックスを守らせる。 ・チェックインなどでコミュニケーションを円滑化する ・心理的に幸福になるように促す |
| 開発チーム | ・製品開発を実施する人。インクリメントを生み出している。 ・クロスファンクショナルに開発ができる。 ・見積もりと開発そのもの(設計〜試験等)に責任を持つ |
| プロダクトバックログ | 要求アイテムを優先順位をつけて、一覧にまとめたもの。 |
| スプリントバックログ | 以下をまとめたもの。 ・スプリントゴールを達成するために必要なプロダクトバックログアイテム ・スプリントゴールを達成するために必要な実行計画(実行計画はタスク分割を行う場合が多く、その場合は日々の進捗がわかるように1時間程度にまで細分化する。) |
| タスクボード・KANBAN | スプリントバックログのタスクをTODO、Doing、Done等の進捗状態を明らかにする形でボード上に配置したもの |
| バーンダウンチャート | スプリントバックログのタスク作業量を縦軸に、横軸に時間経過を置き、作業の増減状態を可視化したもの。本グラフを使って、進捗管理を行うことができる。 ・プロダクトバックログアイテムのストーリーポイントを元に作成すると、リリースまでの見通しを立てるリリースバーンダウンチャートを作成できる。 ・スプリントバックログのタスク時間を元に作成すると、スプリントの進捗を図るスプリントバーンダウンチャートを作成できる。 |
| スプリント | スプリントとは、プロダクト生成サイクルの期間を指す。プロジェクトにより、期間はまちまちだが、振り返り時のフィードバックをこまめにもらえるようにするため、通常は1〜2週間程度(長くても4週間程度)の短いサイクルにすることが多い。 |
| ストーリーポイント | 各プロダクトバックログアイテムを相対見積もりの形でポイントを振ったもの。工数ではない。 注意点としては、見積もりに時間をかけすぎないことが挙げられる(時間を掛けたところで精度はある程度の所で頭打ちになる)。不確実性のコーンといった、そもそも遠い将来のことに対しては正確な見積もり等不可能という考え方もある。 なぜ、ポイントを使うのかについてはこちらのサイトがわかりやすい。 |
| ベロシティ | 1スプリントで進んだストーリーポイント。今後の見通しを予測するのに使われる。 よくある間違いとして生産性指標と扱ってしまうパターンがある。 生産指標のような形でチームを評価するようになると、以下のような弊害を発生する可能性があるため推奨されない。 ・心理的安全性が損なわれ、予防線を張った報告になる。透明性を持った報告がされなくなってしまう。 ・ポイントのみを重視し、必要なストーリーを満たしていないのに完了にしてしまう ・ストーリーポイントの水増し改ざん等により、ありのまま状況を正しく知ることができなくなる。 ベロシティはウォーターフォール開発の文化に慣れ親しんでいると扱いが非常に難しいものになりがちなので、参考になるURLを以下に記載する。 ・https://www.ryuzee.com/contents/blog/14587 ・https://gonkunblog.com/scrum-planning/40/ ・https://products.sint.co.jp/obpm/blog/velocity |
| スプリント | イベント | 主な担当者 | 実施内容 |
| スプリント0 | PO 開発者 SM |
・インセプションデッキを作成する ・顧客UX指針(ペルソナ・カスタマージャーニーマップ・ユーザーストーリーマッピング・エンパシーマップ等)を作成する。 ・Doneの定義を決める。 ・使用するツールの選定。 ・ワーキングアグリーメントの設定 ・この辺のサイト等も参考に、その他キックオフに必要なことを実施する | |
| スプリント1〜N | バックログリファイメント | PO 開発者 SM |
以下のようなことを行い、バックログアイテムの見直しを図る。 ・プロダクトバックログアイテムの内容やその目的を明確化する ・優先順位づけを行う ・受入基準を整理する。 ・プランニングポーカーの形式で各プロダクトバックログアイテムの見積もりを実施する。 |
| スプリント計画(第一部) | PO 開発チーム SM |
・作成したプロダクトバックログを開発チームに共有する。共有時は「何故やるのか」「何をやるのか」「受入基準」等を含め、PO・開発チーム間で認識が合うまで話せると良い。 | |
| 開発者 SM |
・プランニングポーカーの形式で各プロダクトバックログアイテムの見積もりを実施する。 | ||
| PO SM |
・開発チームの見積もりとベロシティ[スプリント2以降]を参照し、費用対効果のバランスを考えて、ストーリーの内容変更や優先順位変更を行う。 ※注意： ・仕様を変更した場合は、開発チームに再見積もりしてもらう。 ・仕様変更のタイミングは、原則このスプリント計画のタイミングで実施すべきで、実際に製造が走り始めてからは原則すべきでない。 ・進捗が芳しくない時等にもQCDは基本的には変えず、スコープを変える。 | ||
| PO 開発者 SM |
・ベロシティを確認する。 ・祝日や休み等、開発チームのキャパシティ度合いを確認する。 ・スプリントゴールの仮合意をする。 | ||
| スプリント計画(第二部) | PO 開発者 SM |
プロダクトバックログからどのように作るかを考えて、スプリントバックログを作成する。疑問があれば、POに確認する。 | |
| PO 開発者 SM |
・スプリントゴールの本合意をする。 | ||
| デイリースクラム | PO 開発者 SM |
・15分以内のデイリースクラムをしつつ、開発を進める。 ・進捗管理はタスクボードやバーンダウンを作成、POと共有することで実施。 | |
| 製造 | 開発者 SM |
・進捗管理はタスクボードやバーンダウンを作成、POと共有することで実施。 | |
| スプリントレビュー | PO 開発者 SM |
・計画したスプリントゴールと今スプリントの結果を共有する ・スプリント内で起きたことや今後の見通し等を共有する ・作成物のレビューを行い、ステークホルダーやスクラムチーム内からフィードバックをもらう。 | |
| スプリントレトロスペクティブ | PO 開発者 SM |
・KPT形式等を用いて、スプリントの振り返りを実施する。 ・振り返り手法は多種多様にあるため、いろいろ試してみると良い。 |
| 要求品質 | ビジネス要求を満たした品質になっているかは、スプリントレビューや市場調査等から図る必要がある。KPIなどを定義しておくことも重要 |
| プロダクト品質 | ・スプリントごとの品質は受入基準で決めることが多い。 ・ウォーターフォールのような品質指標はスプリントの単位だと規模が小さくて、統計的にうまく機能しない場合がある。そのため、スプリントごとのバグ量比較等で代わりとする場合もある。 ・開発スピードが早いため、テスト駆動開発やCI/CD等の自動テスト環境が基本となる。 テストカバレッジを指標にする場合がある。 ・スクラムの考え方ではないが、リリーススプリントというものを設けて総合試験のようなことを実施する場合がある。このタイミングでは品質指標を使用する場合がある。 |
| プロセス品質 | 開発プロセスが適切であれば、作られるものの品質が妥当になるという考え方になる。 ・全スプリントで満たすべき品質基準である「完成の定義」の中で、「常に必要なレビューを完了していること」等を品質を確保するための条件を設定することで品質を高めることができる。 ・スプリントレトロスペクティブ等でプロセスを振り返り、プロセスを改善する。 ・進捗管理が出来ていないと品質管理が犠牲になることも多いため、スプリントゴール達成状況を見る手も有効である。 |
