こんにちわ、かねこです。
今回は、スクラム開発について体系的に学んでみたいな〜と思い始めてスクラム開発に触れる人におすすめされている「SCRUM BOOT CAMP THE BOOK」について読みましたので、自分が良かったなと思った部分であったり、スクラム開発における用語についてざっくりまとめていけたらと思います〜
SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発
基本的な用語
スクラム開発における基本的な用語についてざっくりまとめます。
- プロダクトオーナー
- プロダクトのWhatを担当
- プロダクトの価値を最大化するのが仕事
- プロダクトバックの管理者で最終意思決定件を持つ役割
- スクラムマスター
- スクラムがうまくいくように全体を支援する役割
- ステークホルダー
- プロダクトの利用者や出資者、管理職などの利害関係者
- 開発チーム
- プロダクトのHowを担当
- ものを作る人
- 3〜9人が適切
- 3人以下だと相互作用が少なかったり、個人のスキルに依存するケースになる
- 10人以上だとコミュニケーションスキルが多くなり効率が下がる
- プロダクトバックログ
- 本プロダクトで実現したいことをリストとして書き出したもの。常にメンテナンスを行い最新の状態にしておくことが大切
- 上から順番に優先度が高いものとして開発を進めていく
- スプリント
- １か月までの同じ期間を区切って繰り返す開発サイクルのこと
- 区切った期間の中でプロダクトバックログの項目について設計、開発、テスト、リリースまでを行う
- 期間の長さについては変えてはいけない
- スプリントプランニング
- スプリント内で何を作るのか（What）、どうやって作るのか（How）を計画するイベント
- スプリントで何を達成するのかを決める
- 達成するためのプロダクトバックログを選択する
- 開発チームがどうやってプロダクトバックログの項目を実現するのかについて計画する
- 具体的な作業を洗い出すなど作業計画を立てる
- スプリントゴール
- スプリントプランニングの際に検討した内容を踏まえて今回のスプリントで何を達成するのかについての目標を立てる
- 開発チームがなぜこのスプリントプランニングの項目を開発するのかを理解するために設定する
- スプリントバックログ
- スプリントプランニング内で選択したプロダクトバックログの項目を実現するために必要な作業の一覧を洗いだいたもの
- 作業は基本的に1日以内で終わるように分割するのが良い
- バックログリファイメント
- 次回以降のスプリントに向けてプロダクトバックログの中身や優先度を見直すイベント
- スプリントプランニングを行うための準備のイベント
- 具体的な内容
- プロダクトバックログの中身を具体的にする
- 疑問点を解消する
- 作業の見積もりを行う
- インクリメント
- スプリント単位で評価可能な動作しているソフトウェア
- スプリント終了時点で完成していて正常に動作していないければいけない
- スプリント単位で評価可能な動作しているソフトウェア
- デイリースクラム
- 毎日行うもの（朝会みたいなもの）
- 人数に関係なく15分以内になるようにする
- スプリントバックログの残作業を確認し、このままのペースでスプリントゴールが達成できるかどうかを確認する
- 以下のようなことを情報共有する
- 昨日やったこと
- 今日やること
- 障害になりそうなことはあるか
- このままのペースでスプリントゴールを達成できるかを確認するためのイベントであるため、進捗報告会となってしまってはいけない
- スプリントレビュー
- スプリントの終わり際に今回のスプリントでの成果物についてステークホルダーに対して報告を行うイベント
- 報告する際は実際にアプリが動いている環境で実際に操作を行い求めてものと比べてどうかについてなどのフィードバックをもらう
- スプリントレトロスペクティブ
- スプリント最後のイベント
- スプリントレビューが終わってから行うイベント
- スプリント内での問題点やうまくいったことについて共有し改善事項について検討し、次回のスプリントからか前を行う
- 常に自分たちの仕事のやり方について改善を行なっていく
- ベロシティ
- スプリントごとに完了できる作業のポイント数
- 開発チームの開発スピード
- こちらがわかることで必要な機能をリリースするまでの期間など先に見通しを立てることができる
- ただし、ベロシティ決めるものではなく「測る」ものである
個人的に特に学びがあった部分について
リリースの目処ってどうやって立てるの？
本を読み進めている中で、プロダクトバックログに実現したいことの一覧を作ってスプリントという単位に分けて開発を進めていくということはわかったけど実際にどうやってファーストリリースの目処について立てるのか気になっていたのですが、それについてもこの本に書かれており、私は以下のように理解しました。
- 今後の見通しをしっかりと立てる
- 必要な機能についても洗い出しを行い、漏れがないかをプロダクトオーナー、ステークホルダーと一緒に確認を行う
- その上で必要な機能についての優先度を決める
- ベロシティをしっかりと計測する
- 開発を行う前に見通しを立てた上で数スプリントを回してみて、ベロシティの数値を計算する
- 計算したベロシティをもとに下記のような計算式に当てはめることで先の見通しを立てることができる
絶対に作りたい項目のポイント数÷ベロシティ= 必要なスプリント数
ベロシティ×使えるスプリン数= 実現できるポイント数 - ベロシティがより正確であればあるほど、リリースの時期を正確に見積もることができる
- ただし、リリースに慣れていないうちはリリースのためにやることをまとめたり、準備をしたりするフェーズとしてリリーススプリントというものを設けるのも良いとされている。
もっと早くリリースできないの？
スクラム開発を進めて内に開発チームの開発効率が向上し、ベロシティの数値が上がり順調に開発が進んでいるとクライアントから順調そうだからリリースを前倒しにして欲しいとかリリースのスコープを広げて欲しい。なんなら、予算を増やすから増員してもいいよ。
みたいなことがありそうです。
クライアントの意見も分かりますが、直感的には厳しくね？と思いますが、実際どう返答するのが良いかについてのtipsが書かれており、私は以下のように理解しました。
- 増員したからといってベロシティは向上しない
- 開発効率が上がり前よりもベロシティの数値が一時的に上がったとしてもそれはすぐに安定するし、開発効率が上がっているのは、今まで開発チームが行なってきた改善活動の賜物である。
- スクラム開発のリズムに慣れたことに起因するものなので、途中のタイミングで増員をしたからといって必ずしも増員した分だけ作業効率が高まるわけでもましてや増員経験のないプロダクトの場合、かえって混乱する危険性すらある。
直感的に厳しくね？と思っていましたが、言語化することでなぜ厳しそうなのかについて具体的にできてスッキリしました。
最後に
以上が、「SCRUM BOOT CAMP」を読んでみての私なりの感想です。
普段の業務でもスクラムっぽい感じで仕事を回しておりましたが、今回体系的にスクラム開発について学ぶことができたので、今までの業務でも少しずつ取り入れていって開発効率を高めていきたいと思いました💪
たまには、技術的な学習ではなくこういった開発手法そのものについて学ぶのも新鮮で良いことだと思いました✨
今後もこういった自分の困りポイントだったり設定手順だったりを発信していけたらなと思います🐈
toraco株式会社では2024年11月1日にエンジニア向けのコミュニティを立ち上げました。
Discord のサーバーで運営しており、以下のリンクから無料で参加できます。コミュニティ内では以下のような投稿・活動がされます！
Discussion