目的
下記書籍のポイントをかいつまんでまとめること。
この記事を振り返り内容を復習すること。
読者のレベル感
- ソフトウェア開発の経験がすでにある人が読むとより内容が入ってきやすい印象
- アジャイル開発をこれからチームに導入しようと検討している方向け
ソフトウェア開発の困難にスクラムで立ち向かう
ソフトウェア開発を困難にする要因
- 物質的な不可視性
- 目指す機能的な不可視性
- コミュニケーションの不可視性
これらを解決するにはまず問題を全体として捉えるのでは無く整理、分解することが重要
その方法として、
5w1h フレームワークが推奨されている
特に、
what(目指す機能的な不可視性を解決する)とhow (コミュニケーションの不可視性を解決する)が重要
従来の各工程を他と交わらずに進める開発スタイルをリレー競争型と表現し、
スクラムは各工程が次工程とオーバーラップするように開発を進めるスタイルを指す
スプリント
役割
- プロダクトオーナー
- what
- 課題達成のために何を作るべきか明確に定める
- スクラムマスター
- how
- 人間関係のようなコミュニケーションをどのように円滑に進めるかに責任を持つ
2人のリーダーが存在することが特徴
- 自己組織化（スクラムチームのメンバー全員がチームの理想とする姿を考え、その理想に向かって能動的に学習と成長をし続けている状態）を目指す
ロールと役職は別物
プロダクトオーナー
- プロダクトオーナーは1人
- プロダクトの価値の最大化に責任を持つ
- 何を作るべきかの最終決定権はプロダクトオーナーにある
- 責任の所在を明確にし、プロダクトに妥協を許さないために開発チームとは明確に独立している
- 要件の決定権、優先順位付けの権限もある
開発チーム
- プロダクトオーナーが定めた要件を優先順位に従って開発する専門家の集団
- 3〜9人が望ましい
- 機能横断的であること(プロダクトの完成に必要な能力をチームが持っている事)
- 職種の違いによって区別されない
- スクラムチームや組織がスクラム開発を行う上でのサポートを行う
- 基本プロダクトには関与しない
- チームに1人(4〜10人に1人が適切)
- プロダクトオーナーの支援
- 開発チームの支援
- 組織全体への支援
検査と適応で変化に順応する
スプリント
- スクラムでの開発期間の1単位
- 1w〜1M程度
- リリース判断可能なプロダクトを作る
リリーススプリント
- スプリントの中で残ったタスクを処理する特別なイベント
スプリントプランニング
- スプリント開始時に「スプリント期間内で何ができるか」「どうやって達成させるか」の2点を明らかにするミーティング
- リファインメント(スプリントプランニングの準備→次のスプリントに写れるようにプロダクトバックログを整理する活動
- プロダクトバックログはプロダクトで何を実現すべきかを優先順位をつけて一覧化したもの
- それらの各項目のことをプロダクトバックログアイテムと呼ぶ
- プロダクトバックログアイテムの内容を具体化することで完了とする
- スプリントゴールの設定：ベロシティを参考にスプリント中に達成したい目標やバックログアイテムのこと
- ベロシティ：1スプリントにスクラムチームが完成させることができる仕事量
- スプリントバックログの作成
- スプリントバックログ：スプリント期間内で行うと判断したプロダクトバックログアイテムと、それらのプロダクトバックログアイテムを実現するためのタスクを、俯瞰できるよう一覧化したもの
デイリースクラム
- 1日に1回15分間のタイムボックスで、進捗や予定、問題の共有を行うミーティング
スプリントレビュー
- スプリント期間中に作成したリリース判断可能なプロダクトであるインクリメントの確認を行い、フィードバックを得るためのミーティング
スプリントレトロスペクティブ
