スクラム知らない状態から解像度を上げる
スクラムやることになったので、周辺知識を整理しました。
なお、こちらの記事は SCRUM BOOT CAMP THE BOOK【増補改訂版】を参考にしています。
前提
ソフトウェアを作るのは簡単ではありません。
いざ進めてみると途中でほしいものが変わったり、さまざまな要望が出たりします。
計画通りに物事が進むことは滅多にありません。
市場からのプレッシャーや、ニーズがないと分かれば変化し続ける必要があります。
ソフトウェアを作るうえで本当に重要なこと
それは、できあがったソフトウェアを実際に活用することで顧客や利用者の課題を解決したり、お金を稼いだりする、つまり成果を上げることです。
ソフトウェアを作ること自体は目的ではなく、成果を上げるための手段なのです。
したがって、何のために作るのかを明らかにし、現在作っているものが本当に成果を実現できているのかを小まめに確認しながら進めていくことが必要です。
その過程で当初作ろうと思っていたものよりも良いアイディアが出てくれば、それを受け入れ、作るものを変えていきます。そうすることで成果が最大化していきます。
アジャイル開発とは？
では、目的を達成し、成果を最大化するためには、どう進めれば良いのでしょうか。
それは次のような進め方です。
- 関係者は目的の達成のためにお互いに協力し合いながら進める
- 一度にまとめてではなく少しずつ作り、早い段階から実際に動作するものを届け続けて評価を繰り返す
- 利用者の反応や関係者からのフィードバックを継続的に得ながら、作っているもの自体や計画を調整する
このような進め方をアジャイル開発を呼びます。
アジャイル開発とは何か単一の開発手法を指すものではなく、似たような開発手法に共通した価値観と行動原則に名前がついたものです。
主な手法にスクラム、エクストリーム・プログラミング(XP)、カンバンがあります。
従来の開発手法では、あらかじめすべての要求を集め、すべてを作るためにはどのくらいの期間がかかるのか、どのくらいの人数が必要なのか、どのくらいのコストが発生するのかを見積もります。
一方でアジャイル開発では、どのくらいの期間や人数で仕事をするかを決めて、その範囲の中で大事な要求から順にプロダクト(ソフトウェア、必要なドキュメント)を作っていきます。つまり、重要なもの、リスクの高いものほど先に作り、そうでないものは後回しにすることで成果を最大化していきます。
スクラムってなんだろう？
スクラムは、前述の通りアジャイル開発手法の1つです。
スクラムには以下の特徴があります。
- 要求の価値やリスクや必要性を基準に並び替えて、その順にプロダクトを作ることで成果を最大化します
- スクラムでは固定の短い期間に区切って作業を進めます。固定の時間のことをタイムボックスと呼びます
- 現在の状況や問題点を常に明らかにします。これを透明性と呼びます
- 定期的に進行状況や作っているプロダクトで期待されている成果を得られるのか、仕事の進め方に問題がないかどうかを確認します。これを検査と呼びます
- やり方に問題があったり、もっとうまくできる方法があったりすれば、やり方そのものを変えます。これを適応と呼びます
スクラムはわかっていることよりもわからないことが多いような複雑な問題を扱うのに適しており、5つのイベント(会議など)、3つのロール(人の役割)、3つの成果物など最低限のルールのセットで構成されています。
【イベント1】スプリント
短く区切って繰り返す
- 1ヶ月までの同じ期間に区切って繰り返す
1つの区切りをスプリントと呼ぶ- スプリントは、他のイベントのコンテナ(入れ物)となる
- 期間の長さが変わってはいけない
開発チームはこの期間の中で、計画、設計、開発、テストなどプロダクトバックログ項目を完成させるのに必要な作業すべてを行います。このように固定の期間に区切って開発を繰り返すことによって、開発チームにリズムができて集中できるようになり、全体のゴールに対する進捗が把握しやすくなったり、リスクに対応しやすくなったりします。
たとえスプリントの最終日に作業が残っていたとしても、スプリントは終了し、期間は延長しません。
スプリントの期間は短ければ1週間、長くて4週間と週単位で期間を設定することが一般的です。
【イベント2】スプリントプランニング
頻繁に計画する
- スプリントで開発をするためには計画が必要なので、スプリントの冒頭で実施する
- プロダクトオーナーは何をほしいか(トピック1)
- 開発チームはどれくらいでできそうか(トピック1)
- 開発チームはどうやって実現するか(トピック2)
1つめのトピックは、スプリントで何を達成するか決めることです。
選択するプロダクトバックログの個数は、それぞれの項目の見積もりサイズや開発チームの過去の実績(ベロシティと呼びます)、今回のスプリントで作業に使える時間(キャパシティと呼びます)などを踏まえて仮決定します。
また、検討した内容を踏まえて今回のスプリントの目標を簡潔にまとめておきます。これをスプリントゴールと呼び、開発チームがなぜここで選択したプロダクトバックログの項目を開発するのかを理解しやすくなります。
スプリントプランニングを開始する前に、プロダクトバックログの上位の項目については事前準備が必要です。
例えば、項目の中身を具体的にする、項目の疑問点を解決する、項目は何ができたら完成なのか(受け入れ基準)を明らかにする、項目を自分たちが扱えるサイズに分割する、項目を見積もる、といったことを行います。これらの活動のことをプログラムバックログリファインメントと呼びます(リファインメントと略して呼ぶことも多いようです)。
リファインメントに使う時間はスプリントの10%以内にするのが一般的です。
2つめのトピックとして、開発チームがどうやって選択したプロダクトバックログ項目を実現するかについて計画を立てます。つまり選択したプロダクトバックログ項目ごとに、具体的な作業を洗い出すなどして作業計画を立てます。個々の作業は1日以内で終わるように分割するのが一般的です。
【イベント3】デイリースクラム
毎日状況を確認する
デイリースクラムは、開発チームのための会議です。スプリントバックログの残作業を確認し、このまま進めてスプリントゴールが達成できるのかどうかを、毎日、同じ時間、同じ場所に開発チームが集まって検査します。
デイリースクラムは、開発チームの人数に関係なく、15分間のタイムボックスで行い、延長はしません。
進め方に特に決まりはありませんが、以下の3つの定型の質問に答えることが多いようです。
- スプリントゴールの達成のために、自分が昨日やったことは何か？
- スプリントゴールの達成のために、自分が今日やることは何か？
- スプリントゴールを達成するうえで、障害となるものがあるか？
デイリースクラムは、問題解決の場ではないことに注意してください。
開発チームのメンバーが問題を報告した場合は、デイリースクラム終了後に改めて、問題解決に必要な人を集めた別の会議を設定するなどして、15分のタイムボックスを守ります。
デイリースクラムの結果を踏まえて、開発チームはスプリントの残り時間でどのように作業を進めるかをプロダクトオーナーに報告できるようにしておきます。
【イベント4】スプリントレビュー
できあがったプロダクトを確認する
スプリントの最後に、プロダクトオーナー主催でスプリントの成果をレビューするイベントを開催します。これをスプリントレビューと呼びます。プロダクトオーナーはスプリントレビューに必要な利害関係者(ステークホルダー)を招待します。
スプリントレビューの最大の目的は、プロダクトに対するフィードバックを得ることです。
- 開発チームのスプリントでの成果物(完成したもの)を関係者にデモする
- 事前に完成したもの、完成していないものを区別しておくとよい
- フィードバックを得て、プロダクトバックログを見直す
- 全体の残作業や進捗をトラッキングする
- 今後の予定や見直しを共有する
- プロダクトオーナーが主催
- ステークホルダーに参加してもらう
スプリントレビューで議論した内容は、必要に応じてプロダクトバックログに反映します。
スプリントレビューに使える時間は、1ヶ月スプリントであれば4時間です。
スプリント期間がそれより短い場合は、スプリントレビューも同じように短くするのが一般的です。
【イベント5】スプリントレトロスペクティブ
もっとうまくできるはず
スプリントレビューのあとにスプリント内の最後のイベントであるスプリントレトロスペクティブを行います。
- もっとうまく仕事を進められるようにカイゼンを繰り返す
- バグを直すのではなく、バグが生まれるプロセスを直す
- 人、関係、プロセス、ツールなどの観点で今回のスプリントを検査する
- うまくいったこと、今後の改善点を整理する
- 今後のアクションプランを作る
- 一度にたくさんのことを変更しようとしない
仕事のやり方を常に検査して、より良いやり方に変え続けていくことはアジャイル開発における重要な点の1つで、スクラムではスプリント単位でそれが行われるように仕組み化されています。
スプリントレトロスペクティブで使える時間は、1ヶ月スプリントであれば3時間で、それより短い期間であれば期間に応じて時間を短くするのが一般的です。
【ロール1】プロダクトオーナー
プロダクトの責任者はだれ？
- プロダクトのWhatを担当
- プロダクトの価値を最大化する
- プロダクトの責任者(結果責任)で、プロダクトに1人必ず必要
- プロダクトバックログの管理者
- プロダクトバックログ項目の並び順の最終決定権限を持つ
- プロダクトバックログ項目が完成しているかどうかを確認
- 開発チームに相談できるが干渉できない
- ステークホルダーとの協業
開発チームを活用して、そのプロダクトが生み出す価値を最大化する必要があります。
そのためにプロダクトバックログの並び替えのほかに、次のようなことを行います。
- プロダクトのビジョンを明らかにし、周りと共有する
- おおよそのリリース計画を決める
- 予算を管理する
プロダクトバックログの作成や更新は、プロダクトオーナー(PO)1人だけでなく、開発チームらとともに行う場合もありますが、最終的な責任はプロダクトオーナーにあります。
プロダクトオーナーが決めたことを他人が勝手に覆してはいけません。プロダクトオーナー自身が決めることで、結果に対して責任を持てるようになります。
【ロール2】開発チーム
動作するプロダクトを開発する
- プロダクトのHowを担当
- モノを作る
- 3人〜9人が適切な規模
- 全員が揃えばプロダクトを作る能力が揃う
- 肩書きやサブチームはなし
開発チーム内での仕事の進め方は、開発チームのメンバーの合意のもとで決め、外部から仕事の進め方を仕事の進め方を支持されることはありません。これを自己組織化と呼びます。
このように開発チームで主体的に作業を進めることによって、開発チームの能力は継続的に向上していきます。
【ロール3】スクラムマスター
縁の下の力持ち
スクラムではプロダクトオーナーがプロダクトバックログを並び替えて、開発チームはスプリント単位でプロダクトを作っていきます。そのプロセスを円滑にまわして、プロダクトをうまく作れるようにプロダクトオーナーや開発チームを支えるのが、スクラムマスターです。
- このフレームワーク・仕組みがうまくまわるようにする
- 妨害の排除
- 支援と奉仕(サーバントリーダーシップ)
- 教育、ファシリテーター、コーチ、推進役
- マネージャーや管理者ではない
- タスクのアサインも進捗管理もしない
スクラムマスターは、スクラムのルールや作成物、進め方をプロダクトオーナーや開発チームに理解させ、効果的な実践を促し、スクラムの外にいる人からの妨害や割り込みからプロダクトオーナーや開発チームを守ります。
以下は、スクラムマスターがプロダクトオーナーや開発チームに対して行うことの一例です。
- プロダクトオーナーや開発チームにアジャイル開発やスクラムについて説明して理解してもらう
- スプリントプランニングやスプリントレトロスペクティブなどの会議の進行を必要に応じて行う
- プロダクトオーナーと開発チームの会話を促す
- プロダクトオーナーや開発チームの生産性が高くなるように変化を促す
- わかりやすいプロダクトバックログの書き方をプロダクトオーナーや開発チームに教える
- プロダクトバックログの良い管理方法を探す
プロダクトオーナー、開発チーム、スクラムマスターを合わせてスクラムチームと呼びます。
【作成物1】プロダクトバックログ
機能や要求を並び替える
- 実現したいことをリストにして並び替える
- 優先度ではない
- 常にメンテナンスして最新に保つ
- 項目が追加されたり、削除されたりする
- 順番は定期的に見直す
- 上位の項目は見積もりを済ませておく
それぞれの項目はプロダクトバックログ上で一意な順番を持ち、順番が上位のものから開発します。
そのため上位の項目ほど内容が具体的で詳細なものになります。
見積もりには作業の量を相対的にあらわした値がよく使われています。
項目の書き方はとくに決まりはありませんが、ユーザーストーリーと呼ばれる形式で書くことが多いようです。
【作成物2】スプリントバックログ
- 選択したプロダクトバックログ項目と実行計画
- プロダクトバックログを具体的な作業に分割する
- 後から増えることもある
- 1タスクは1日以内で終わるサイズ
スプリントバックログを検討した結果、トピック1で検討して選択したプロダクトバックログ項目を完成させるのが難しいと開発チームが判断した場合は、プロダクトオーナーと相談し、選択したプロダクトバックログの項目の一部を外したり、作業計画を検討し直したりすることによって、作業量を調節します。
注意しなければならないことは、開発チームはスプリントプランニングで合意した内容を完成させるように全力を尽くす必要があるものの、計画したことをすべて完成させることを約束しているわけではないという点です。
すべての完成を約束してしまうと、見積もりが外れたり、難易度が高かったり、不足の事態が発生したりした場合に、開発チームが長時間残業したり、必要な作業を省いたりしてしまうかもしれません。その結果、プロダクトにさまざまな問題が発生することになります。
スプリントバックログの項目の担当者を特定の人が決めることはありません。
実際の作業に着手するときに、作業する人自身がスプリントバックログの項目を選択するようにします。
【作成物3】インクリメント
スプリントごとに完成させていく
- 開発チームは完成したインクリメントを作成
- インクリメントではこれまでのスプリントでの成果と今スプリントで完成したプロダクトバックログ項目を合わせたものを指す
- リリースするかどうかに関係なく動作して検査可能でなければならない
スクラムでは、スプリント単位で評価可能なインクリメントを作ることが求められます。
動作しているソフトウェアは、スプリント終了時点で完成していて正常に動作しなければいけません。そのため、プロダクトオーナーと開発チームが「完成」の指す内容について共通の基準を持つ必要があります。
これを完成の定義と呼びます。開発チームは、この定義を満たしたプロダクトを作らなければなりません。
完成の定義
- 何をもって「完成」とするかの基準を定める
- スプリントでどこまでやるか決める
- 以下はあくまで一例。プロダクトオーナーと開発チームで事前合意する
(コードレビュー、ユニットテスト、カバレッジ85%、ドキュメント、性能、セキュリティ、デプロイ)
スクラムの5つの価値基準
スクラムを活用して良い結果を生むためには、スクラムの５つの価値基準を取り入れて実践していく必要があります。
- 確約：それぞれの人がゴールの達成に全力を尽くすことを確約する
- 勇気：正しいことをする勇気を持ち、困難な問題に取り組む
- 集中：全員がスプリントでの作業やゴールの達成に集中する
- 公開：すべての仕事や問題を公開することに合意する
- 尊敬：お互いを能力ある個人として尊敬する
Discussion