前の記事で流行りのアジャイルについて手法を含め少しまとめましたが、今回はアジャイルでよく聞くスクラム開発とはなんぞということで深堀していく。
＜前回の記事＞
https://qiita.com/matsukazu/items/319008d9fd7c5d129018
スクラム開発ってなに？
- アジャイルの手法がスクラム開発
- アジャイルの中でもスクラム開発が一番使われている手法
- そのほかに、かんばんやXPなどの手法があるが、単体で使うというより組み合わされて使われることが多い（スクラムとかんばん、スクラムとXPとか）
メンバー
ステークホルダー
- 利害関係者（発注元、顧客など）
プロダクト・オーナー
- プロジェクトの方向性を決める責任者
- ステークホルダーとのコラボレーション
- すべてのワークフローにかかわる
- 予算の支出の管理
- 計画の責任
- 受け入れ基準を定義し、それらを満たしていることの確認
- 大規模な場合はプロダクトオーナーチームを作る場合もある
スクラムマスター
- プロジェクトの進行役
- 開発チームのコーチング
- サーバントリーダー
- チームの注力が散漫することを削除する（プロジェクトに関係のない仕事などをできるだけ排除）
- 開発チームの進行状況を常に確認する
開発チーム
- エンジニア、デザイナーなどなど（4~6人くらい）
- 大規模な場合は開発チームを増やしていく
- T字スキルがあると良い
- 専門分野だけではなく、いろいろできると良い
- 流動的に動く
スクラム開発の流れ
- 製品ビジョンに対して、下記の工程を繰り返して製品を作り上げていく
- プロダクトバックログの作成、見直し
- スプリントプランニング
- スプリントバックログ作成
- スプリント
- デイリースクラム
- インクリメント
- スプリントレビュー
- スプリントレトロスペクティブ
用語解説
プロダクトバックログ
- 製品ビジョンに対して、実現したい機能のリスト
- ユーザーストーリーと呼ばれる形式で書くことが多い
- 実現したい機能の優先順位をつける
- 常に見直して、最新に保つ
スプリントプランニング
- スプリントで何を実現したいのかを決める
- プロダクトオーナーは何が欲しいのか
- 開発チームはどれくらいできそうか
- 開発チームはどのように実現するのか
スプリントバックログ
- 実行するプロダクトバックログ項目と実行計画
- プロダクトバックログを具体的な作業に分割する
- 後から増えることもある
スプリント
- 頑張って機能を作る
- 大体二週間くらい（プロジェクトの方針による）
デイリースクラム
- ゴール達成に向けて進んでるか確認する
- 作業進捗を確認し、問題や課題などを共有する
- スクラムチームごとに毎日やる
インクリメント
- これまでと今回のスプリントで作成したプロダクトバックログの項目を合わせたもの
- リリースするか関係なく、動作して検証可能でなければならない
スプリントレビュー
- スプリントのインクリメントをスクラムチームとステークホルダーがレビューする
- 必要に応じてプロダクトバックログの適応を行う
スプリントレトロスペクティブ
- チームの改善アクションの検討
- チームの文化を育てる
- 知識などの共有
チーム構成
- フィーチャーチーム
- 機能ごとにチームをわける
- クロスコンポーネント
- コンポーネントチーム
- 機能実装に必要な一般的な機能を開発する
- スクラム・オブ・スクラム
- チームごとの技術者リーダーの情報交換の場
顧客とのエンゲージメント
- ウォーターフォール
- ほとんど初期の段階と製品の完成のみ
- スクラム
- 常に一定に顧客とのエンゲージメントをとる必要がある
作業強度
- ウォーターフォール
- 時間がたつにつれて上がってくる
- スクラム
- 期限に向かって上がっていくことはあまりない
まとめ
- 個人的にはウォーターフォールより楽しそう
- 管理ツールはとりあえずJIRAを使うといいらしい