第二章 スクラムフレームワーク
スクラムは作業をまとめ上げ、管理するためのフレームワーク。
このフレームワークは価値・原則・プラクティスに基づいている。
それらを基礎として、組織にあったエンジニアリングプラクティスや、スクラムのプラクティスを実践するための具体的なアプローチを追加できる。
その結果独自のスクラムが現れる。
スクラムの価値・原則・プラクティスは重要な構成要素であり、これらを無視したり、スクラムを本質的に変更しようとすれば、崩壊の危険を冒すことになる。
スクラムの構造の内部をカスタマイズし、備品や機能を付け加えてプロセスを作り上げる。
スクラムの役割
スクラム開発は、一つ以上のスクラムチームから構成される。
各チームには以下の３つのスクラム役割がある。
- プロダクトオーナー
- 何をどういう順番で開発するかに責任を負う
- スクラムマスター
- スクラムフレームワークに基づき、開発チームが独自のプロセスを作り、従えるようにする責任を負う
- 開発チーム
- プロダクトオーナーに依頼されたものをどのようにデリバリーするかを判断する責任を負う
プロダクトオーナー
プロダクトのリーダー権限を与えられている。
どの機能をどの順番に構築するかを判断する責任を持つのは、プロダクトオーナーのみ。
プロダクトオーナーは、スクラムチームが達成しようとするものについて明確なビジョンを持ち、それを開発者全員に伝える。
プロダクトオーナーは、開発や保守も含めたソリューション全体を成功させる責務も負う。
プロダクトオーナーは最も価値が高い作業が行われるようにする義務を負う。
プロダクトオーナーが要求するものをチームが素早く構築するには、プロダクトオーナーと開発チームが積極的に協力する必要がある。
また、質問にすぐ答えられるようにする。
スクラムマスター
スクラムマスターは、スクラムの価値・原則・プラクティスを関係者全員が理解し、受け入れるように手助けをする。
コーチとして振る舞い、プロセスについてリーダーシップを発揮して、スクラムチームや組織がパフォーマンスの高い、独自のスクラムアプローチを育てられるようにする。
他に、。スクラムの適用によって組織変革が行われる際に変革のマネジメントを支援する。
スクラムマスターは、チームが課題を解決しスクラムの利用を改善できるように手助けをする。
また、外部から横槍を入れられることがないようにチームを守り、インベディメント(※ゴルフのコース上にある小石など)を取り除くことにリーダーシップを発揮し、チームの生産性を妨げられないようにする。
スクラムマスターはチームをコントロールする権限を持たない。
開発チーム
開発チームはプログラマ、テスター、データベース管理者、UIデザイナの集まり。 開発チームは、望まれるプロダクトを設計、開発、テストする責任を持つ。
開発チームは5~9人で構成される。
スクラムのアクティビティと作成物
スクラムの流れはスプリント内で以下の順序で実行される。
- プロダクトバックログ
- スプリントプランニング
- スプリントバックログ
- スプリントの実施
- デイリースクラム
- 出荷判断可能なプロダクトインクリメント
- スプリントレビュー
- スプリントレトロスペクティブ
プロダクトバックログ
プロダクトオーナーは、組織内外のステークホルダーと協力して、プロダクトバックログアイテムを収集して、定義する。
そして、プロダクトバックログアイテムを正しい順序で並べる。
プロダクトバックログは常に変化する成果物であり、ビジネスの状況が変わったり、スクラムチームのプロダクトに対する理解が深まったりすれば、それに合わせてアイテムを追加・削除・修正する。
プロダクトバックログアイテムを作り、修正し、また見積もり、優先順位をつけるアクティビティはグルーミングと呼ばれる。
スプリントとは
スクラムでは、作業はイテレーションまたは、サイクルで行われる。
期間は長くても一ヶ月でスプリントと呼ばれる。
スプリントはタイムボックス化されおり、開始日と終了日は常に決まっており、毎回同じ期間でなければならない。
前のスプリントが終わったらすぐに次のスプリントが始まる。
ゴールに影響があるスコープや人員などの変更はスプリント期間中に行ってはならない。
スプリントプランニング
スプリントプランニングでは、プロダクトオーナーと開発チームはスプリントゴールについて合意する。
スプリントゴールでは、次のスプリントで何を達成することになるかを定義する。
このゴールに向けて開発チームはプロダクトバックログのレビューを行い、次のスプリントで現実的に達成できる優先順位の高いアイテムを判断する。
スプリントでは、チームが持続可能なペースで作業する。
達成すべきタスクを第二のプロダクトバックログとなる、スプリントバックログに入れる。
開発チームは、各タスクを達成するために必要な作業の見積もりを提示する。
プロダクトバックログから一つアイテム選び(できるだけ優先順位の高いのを選ぶ)、タスクに分解し、選んだアイテムがスプリントに収まるかを判断する。
もし、スプリントに収まりそうで、もっと他に作業できる作業があるなら、なくなるまで同じ作業をする。
スプリントの実施
スプリントプランニングを終えたら、開発チームは機能を完成させるために必要なタスクレベルの作業を実施する。
スプリントバックログに含まれるタスクについて、どの順番でどのように実施するかについて、開発チームに指示を与える人はいない。
チームメンバーがタスクレベルの作業を定義し、スプリントゴールを達成する上で最善と思われる方法で、実施する。
デイリースクラム
スプリント期間中は毎日、同じ時間に開発チームは15分以内のデイリースクラムを実施する。
デイリースクラムでは、スクラムマスターがファシリテーションを行い、各チームメンバーが順番に、他のチームメンバーに向けて３つの質問に答える。
- 前回のデイリースクラムのあと、自分は何をしたのか
- 次回のデイリースクラムまでに、どんな作業をしようとしているのか
- 進捗の妨げとなる障壁またはインペディメントはなにか
デイリースクラムでは、スプリントバックログのアイテム状況について、開発メンバー間で共有するためのものであるため、開発メンバーのみが発言をする。
出荷判断可能なプロダクトインクリメント
スプリントの成果をスクラムでは、出荷判断可能なプロダクトインクリメントと呼ぶ。
TODO: ピンとこないので４章を呼んだあとでまとめる
用語の定義を調べてみると、完成の定義を満たしており、出荷しようと思えば出荷できるプロダクトのことらしい。
スプリントレビュー
スプリントレビューでは、スクラムチーム・ステークホルダー・スポンサー・顧客・その他チームで興味を持っている人たちと会話をする。
会話の内容は、できたばかりの機能の開発アクティビティ全体というコンテキストにおけるレビュー。
詳細は21章を参照
スプリントレトロスペクティブ
スプリントレビューと、次のスプリントの間に行われる事が多い。
スプリントレトロスペクティブでは、プロセスについて検査と適応と行う。
スプリントレトロスペクティブの間、開発チーム・プロダクトオーナー・スクラムマスターは一緒になって、スクラムとそれに関連する技術的なプラクティスについて、何がうまくいき、何がうまく行かなかったのかを議論する。
継続的なプロセスの改善を焦点とする。
レトロスペクティブの最後に、スクラムチームは現実的な数のプロセス改善アクションを定義し、その実施をコミットしなければならない。
それらを次のスプリントで取り組む
詳細は22章を参照
ここまでの感想や実際の現場との差異
また、現在のプロダクトバックログにはすでにタスクレベルまで分解してあるので、スプリントプラニングでは純粋にスプリント内に収まるかどうかのみを焦点として行っている。
より忠実にするなら、プロダクトバックログには、「Xを作る」という大きな機能のみを入れて、スプリントプランニングで、その中には、「Yを設計する」「Xのデザインをする」などのタスクに分解し、そのタスクをスプリント内で実行していくといった手法にするとかが考えられる。
現在のストーリーポイントの基準が一タスクとなっているので、プロダクトバックログに入れるべきレベルのアイテムを基準としたほうがいいかもしれない。