アジャイル開発を実現するスクラム開発についてまとめてみた
はじめに
クラウドでアプリケーションを開発する大きなメリットとして、すばやくリリースすることができることにあります。それを実現するアジャイル(すばやい)開発手法、「スクラム開発」についてまとめてみました。開発するアプリケーション(プロダクト)で実現したいこと、要求される機能ごとに開発し、ステークホルダーへデモンストレーションを行ってリリースする、これを短い期間(スプリント)で繰り返し行う開発手法になります。
クラウドファースト、クラウド・バイ・デフォルト原則でクラウドへの移行(IaaSへのマイグレーション)は進んでいますが、今後は更なるクラウド化、クラウドネイティブなアプリケーション開発に欠かせない開発手法です。
スクラム開発に必要なロール
スクラム開発を進めるためには、"プロダクトオーナー"、"開発チーム","スクラムマスター"の3つのロールが必要になります。
| # | ロール | 概要 |
|---|---|---|
| 1 | プロダクトオーナー | ステークホルダーと協議して、開発するアプリケーション(プロダクト)に求める機能を整理し、プロダクトバックログとして管理します。 |
| 2 | 開発チーム | プロダクトバックログで管理された項目を開発します。機能要件から設計、コーディング、インフラストラクチャーの構築を行います。 |
| 3 | スクラムマスター | スクラム開発がうまく進められるようにします。教育、ファシリテーター、コーチ、あるいは無茶な要求などの妨害からチームを守ります。 |
スクラム開発の作成物
1.プロダクトバックログ
実現したいこと、実装する機能をリストアップします。これは開発するアプリケーション(プロダクト)につき1つと決められていて、複数のプロダクトバックログは作成できません。開発チームはプロダクトバックログにある項目ごとに作業量を見積もります。これは具体的な作業時間などを見積もるのではなく、相対的なポイントで表現します。ポイントはフィボナッチ数(1,2,3,5,8,13...)といわれる数字で表現します。
プロダクトバックログ例
| # | 機能 | 目的 | 詳細 | 見積 |
|---|---|---|---|---|
| 1 | 日報入力機能 | 最新の情報をもとに営業戦略を検討したい | 日単位で訪問先、日次、担当者、案件情報を入力する | 5 |
| 2 | ログイン機能 | 機密情報のため利用者を制限したい | 全社員が社員番号とパスワードで認証する | 3 |
| 3 | 取引先検索機能 | 事前情報を持った状態で有利にやり取りしたい | 業種、会社名、会社規模、重要度などで取引先を検索する | 8 |
2.スプリントバックログ
開発作業のタスクをリストアップします。プロダクトバックログから開発する項目(機能)を選択し、その開発に必要な作業を具体的に分割してタスク化します。1タスクは1日以内で終わるサイズにして表現します。プロダクトバックログで設定した作業量見積が連動するよう調整します。
スプリントバックログ例
| 機能 | タスク1 | タスク2 | タスク3 |
|---|---|---|---|
| ログイン機能 | Webサーバー構築 | ID・パスワード入力画面作成 | ID認証機能開発 |
3.インクリメント
開発チームが開発して完成したアプリケーション(プロダクト)です。スプリント単位で評価可能なインクリメントを作ることが求められます。(スプリントについては後述します)
スプリント終了時点で正常に動作し完成している必要があるため、予めステークホルダーやプロダクトオーナーと開発チームで何をもって"完成"とするのか、完成の基準を設定します。(完成の定義)
完成の定義例
- コードレビュー
- ユーザー受け入れテスト(UAT)
- 静的解析(SAST:Static Application Security Testing)
- 性能(パフォーマンス)
- ドキュメント(基本設計書、詳細設計書、パラメータシートなど)
スプリント開発
スクラム開発では、短い固定の期間に区切って繰り返し開発を行います。この繰り返し開発を行う工程の単位を「スプリント」といいます。プロジェクトの規模によってこのスプリントの期間を調整しますが、途中で期間の長さを変更することはできません。最長1ヶ月として、1週間、または2週間で期間の長さを設定し、プロダクトバックログにある項目をすべてリリースするまで繰り返します。
1.スプリントプランニング
何度か繰り返し行われるスプリント、その中でその回ごとにプロダクトバックログにある項目からどれを開発するのか計画します。プロダクトオーナーはどの機能を実現したいか、何を達成したいのか毎回"スプリントゴール"を設定し、開発チームはどれくらいでできそうか、どうやって実現するかを計画します。計画した内容を「スプリントバックログ」にまとめます。
2.スプリントレビュー
スプリントの最終日に、開発チームがスプリントで開発した成果物を関係者へデモンストレーションを行い、フィードバックを得てプロダクトバックログを見直します。スプリントレビューはプロダクトオーナー主体で行われ、全体の残作業や進捗についてステークホルダーへ報告します。
3.スプリントレトロスペクティブ
スプリントレビューの後、スクラムマスターを中心にもっとうまく作業を進められるよう改善を繰り返します。バグを直すのではなく、バグが生まれるプロセスを直したり、コミュニケーションやプロセス、ツールなどの観点でスプリントの状況を見直して、今後のアクションプランを作ります。
ベロシティ
1つのスプリントで終わらせられる作業量見積の合計を指します。
スプリント開発を繰り返し行いながら、1つのスプリントの中でどのくらいの作業量を終えることができるのか、プロダクトバックログで見積もった作業量見積のポイントから算出します。このベロシティが分かることによって、アプリケーション(プロダクト)の完成までにかかる期間が試算できます。
アプリケーション(プロダクト)リリースまでの期間試算例
- プロダクトバックログにある項目の作業量見積が合計：300ポイント
- スプリントの長さ：2週間
- ベロシティ：20ポイント
300ポイント ÷ 20ポイント = 15スプリント
15スプリント × 2週間 = 30週間
まとめ
アジャイル開発は「スクラム開発」で実現できます。このスクラム開発には「プロダクトオーナー」、「開発チーム」、「スクラムオーナー」という3つのロールが重要です。また、スクラム開発では開発期間を固定して、繰り返し開発とリリースを行う「スプリント」がアジャイル開発を実現する大きなポイントとなります。
主な流れを以下に示します。
おわりに
スクラム開発は奥が深く、やりながらその時の状況に応じて臨機応変に対処していく柔軟性が求められるため、チーム力が重要な開発手法になります。途中で開発チームのメンバーを交代したり、増員、減員すると、せっかく順調に進められた開発も速度や正確性が低下するため、なるべくスクラムチームの途中変更は避けないといけません。
従来のウォーターフォール開発に比べ、きわめて合理的な開発手法だと理解できる一方、ステークホルダーにもレガシーな考え方をあらためてもらい、クラウドネイティブな思考をもってもらう必要があるのだと理解しました。
Discussion