- 少し前に読んだのでアウトプットします。
SCRUM BOOT CAMP The Book 第1版を読む Vol.1
SCRUM BOOT CAMP The Book 第1版を読む Vol.3
基礎編おさらい
アジャイル開発の前提
- 事前にすべてを正確に予測し、計画することは出来ない
Scrumの要素
成果物
| 名前 | 説明 |
|---|---|
| プロダクトバックログ | 実現したい要求をリストにして並び替える。常にメンテナンスして保つ |
| スプリントバックログ | 開発チームの作業計画 |
| リリース判断可能なプロダクト | 開発したもの |
ロール
| 名前 | 説明 |
|---|---|
| プロダクトオーナー | プロダクトの責任者。結果責任を取る。PBLの管理、並び替え、最終決定権者 |
| 開発チーム | リリース判断可能なプロダクトを作る、自己組織化されたチーム |
| スクラムマスター | プロセスがうまく回るようにする |
会議体
| 名前 | 説明 |
|---|---|
| スプリント計画MTG | 何を作るのか、どのように作るのかを計画する |
| デイリースクラム | 開発チームは毎日、同じ場所、同じ時間に状況を確認する会議を開催する |
| スプリントレビュー | 開発チームの成果物をプロダクトオーナーが確認する |
| スプリントレトロスペクティブ | 振り返り |
その他用語
| 名前 | 説明 |
|---|---|
| スプリント | 最長1ヶ月までの固定の期間に区切って、繰り返し開発を行う。この期間をスプリントと呼ぶ。 |
実践編
P42〜91
実際にScrumでプロジェクトを進めるうえで、大切にしなければならないことを説明する
（本には漫画で書いてあります。）
00プロジェクト概要と人物紹介
- ステークホルダー
- プロダクトオーナー
- スクラムマスター
- 開発チーム
01 ロールを現場に当てはめる
プロダクトオーナーは誰だ？
スクラムチーム
- ロールは役割、偉さではない
- プロダクトオーナー
- スクラムマスター
- 開発チーム
プロダクトオーナーは誰がなるといい？
プロダクトオーナーの作業
- プロジェクトのビジョンを伝える
- プロジェクトのゴールとなる、最終的に達成して欲しいことを伝える
- etc.
要求、仕様、計画に深く関係する作業を行う
どうやって見つける？
- 資格持つひと？上記になれてる人？調整上手な人？
-
最も大事なポイントは何
-
ロールで求められている事に一生懸命取り組んでくれるかどうか（スキルや業務経験も最も大事だが）
-
スキルが足りてないときは？
- 他の人との協力
- 研修を受けさせてもらう
- 勉強会
-
熱意がないと難しい
うまく出来てないことはスクラムチームで補う
- 実際にロールを当てはめようとした時、肩書で決めてはいけない
ロールは単なる目印
- プロジェクトの開始時に適任の人がいるなら、ぜひ参画してもらう
- ロールの兼任は駄目
-
本では、情熱がある、営業に移動した、問題もわかってて、開発者と対等に話せる
きみちゃんがプロダクトオーナーになりました。
みんなでロールを決めてみよう
現場の人に全員集まってもらって、誰が何に向いているのかを話し合う。
02 プロジェクトを理解する
どんなプロジェクト？
プロジェクトの行く先を知っておこう
- プロダクトバックログが必要
- そのために必要なこと
- 何を作るのか（ゴール）
- 最低限の機能
- 絶対に達成すべきことは何か（ミッション）
- いつまでにリリース
- 何を作るのか（ゴール）
- そのために必要なこと
ゴールとミッションはどのように考える？
- プロダクトオーナーが深く関係する
- ゴールとミッション達成の為にPBLを管理する必要がある
- スクラムでは特にゴールとミッションを皆が強く意識する事が大事
- ゴールやミッションだけでは足らない
- インセプションデッキ
- プロジェクトを始める前に明らかにしておくべきことを知るための活動
- 10個の質問形式としてまとめられている
- それぞれの項目に関してスクラムチーム全員で話し合う
インセプションデッキ
- 背景にある考え（詳しくは「アジャイルサムライ」）
- 然るべき人を同じ部屋に集めてプロジェクトにまつわる適切な質問をすれば、自分たちのプロジェクトにまつわる期待を共有して、認識を合わせる事ができるはずだ。
- エレベーターピッチ
- 今から作るものに予算がつくほどの大きな期待がかけられている理由を知るために質問
- 誰に向けたもの
- 何が出来る
- 他と比べてどういう利点があるのか
- 今から作るものに予算がつくほどの大きな期待がかけられている理由を知るために質問
- 我々はなぜここにいるのか
- 達成しないとプロジェクトの意味が失われてしまう理由を明らかにする質問
- やらないことリスト
- 期間を見極める
インセプションデッキどうやって作るの？
- 必要な情報を収集して、皆で話し合う
- 一方的な説明では駄目
- 形だけ集まっても駄目
- スライドにまとめる
03 プロダクトバックログを作る
いつ頃終わるのか
- 大丈夫だと思える見通しを立てる
- プロダクトバックログで管理する
- ただのTODOリストではない
- ユーザーストーリーで書くチームも多い
最初に作る時の注意
- プロジェクトに深刻な影響を与えるような重要事項が、漏れないようにする
- 皆で大量に書き出す
- 一つ一つに順位をつける
- 自分たちで順序をつけることで、自分たちが大丈夫だと思えるようにする
- 全体は大まかに順序を決める
- 直近は詳細
PBLで全体の大まかな流れがわかる
- スクラムチームがPBLについて十分に理解しておくことが重要
- 各項目を見積もればおおよその見通しが立つ
- 見通しに時間をかけすぎてもいけない
- 致命的なことを見落とさないことが大事
04 見積もりをしていく
正確に見積もれない
- Scrumでは見積もりの方法については決めていない
- プロダクトバックログの項目を終わらせるためにどれくらいの作業量があるかに注目する
- 作業量はどうやって表すのか
- 相対見積もり
- 見積もりの対象が不確実なものだということが前提としてある
- 基準となる数字を決めて、それと比較で作業量を考える
- PBLの項目のどれかを基準とする
- 具体的な作業がイメージできるものに適当に数字をつける
- 簡単すぎたり、難しすぎるのを基準にしてはいけない
- 簡単、少し難しい、大いに難しい
- フィボナッチ数列を使う
- 相対見積もり
- 見積もりは推測ということを忘れてはならない
- 素早く見積もる
- 作業量を数値にしたものポイントと呼ぶ