Highlight
-
17:17 スクラムの概要
作成物
プロダクトバックログ スプリントバックログ
- スプリントプランニングで作業項目を詳細化して作る
- これXPだと考えられないな…、 インクリメント（動作するソフトウェア）
ロール
プロダクトオーナー 開発チーム スクラムマスター
POがバックログを並び替える 開発チームは全員揃えばプロダクトが作れる、機能横断的チーム スクラムマスターはまねじめんとするわけではない ファシリテーションやスクラムのメリットについて説明する役割
イベント
スプリント スプリントプランニング
- POは何が欲しいか、どれくらい作れそうか
- どうやって実現するか デイリースクラム
- 昨日何やったか
- 今日何やるか
- 障害になってることがあるか スプリントレビュー
- インクリメントをデモで見せる
- 完成しなかった項目について説明
- バックログに追加すべきことを議論
- POがプロダクトの状況について説明 レトロスペクティブ
-
17:18 スクラムの価値基準
- 確約（ゴールの達成に全力を尽くすことを確約する)
- 勇気（正しいことをする勇気)
- 集中（ゴールの達成に集中)
- 公開（情報、問題を公開)
- 尊敬
-
17:26 「もしこういう機能があればいいのに」と言ってるような人がPOに相応しい ロールが求められることに熱意を持って取り組める人を探す
ドメインエキスパートがPOやるのが良さそう
-
17:30 「要件が決まったら開発しますよ」ではない 要件もスクラムチーム全員で考える プロダクトバックログ ≒ 要件を作るには進んでいく先のことを知る必要がある インセプションデッキを作るとゴールを知れる
-
17:33 ユーザーストーリー 「ユーザーは◯◯したい。それは▲▲だからだ」
特に意図の部分が大事 なおかつ簡潔に書くことによってスクラムチームが着手前に話さざるを得ない状況をあえて作ることができる
もし物理的な制約などで頻繁に話すことができない場合は画面イメージ、受け入れ基準などでストーリーの詳細を補足する必要がある（とはいえドキュメントより対話を重視すべき）
-
17:41 プロダクトバックログ 必要だと思うストーリーを可能な限り書き出す それぞれ優先度を割り当てる（超重要、重要、普通、あればうれしい） あとは上から順に並び替える
-
18:03 見積もり スクラムチームは作業の量で見積もりをする 量を考えると実際にやる作業について考えなくてはいけないため、ヌケモレを防げる 「簡単、少し大変、結構大変」くらいの3段階で分ける その中の真ん中のイメージしやすいものをゴールデンストーリーとして、相対見積もりする
見積もりのポイントはフィボナッチ数を使う 1, 2, 3,2, 8, 13, 21…
-
18:11 スケジュール 総見積もり数÷ベロシティで必要なスプリント数がわかる ベロシティ×実施できるスプリント数で実現できるポイントがわかる
-
21:03 スクラムイベントにはタイムボックスが設定されている 例えばスプリントを1日伸ばすとベロシティに影響が出て正しく完了日を見積もることができなくなってしまう タイムボックスから出たら次のイベントに回すだけ
-
21:13 プロダクトバックログは誰でも追加してok 開発者でも、スクラムチームのメンバー以外でも良い 例えば既存のストーリーを分割することも良い とりあえず下の方に入れて、プランニング時に優先順で並び替える
-
21:23 スクラムイベントは最低限参加してほしいイベント 全員集まらないなら集まるようにするか、フォローアップする必要がある
例えばスプリントレビューにPOがいないというのはNG POを補佐して時間を作るのもスクラムマスターの仕事
-
21:29 ベロシティはあくまでチームの状態 不健全に上げる方法はいくらでもある（ポイントを多めに見積もる、実装を適当にする） そもそも安定していないベロシティは予測に使えない
スクラムマスターが開発の妨げになるものを排除していくことで、健全にベロシティを上げることはできる
-
21:47 スクラムチームが開発を進めるうえでの問題を取り除くのがスクラムマスターの仕事 例えばボードに問題を貼ってもらうようにして、日々改善していく、など
「TDDを知っている人を見つけて勉強会を開いてもらう」 「CI/CDを整備する」 なんかプラットフォームエンジニアリングっぽい
-
21:56 プロダクトバックログのメンテナンス
まず誰でも書けるようにする、少しの変化も見逃さないため
次に優先順位付けを見直す（PO）
- 下の方に大事なストーリーがないか？
次に見積もり直す（開発）
- 上の方で見積もりされていないものがないか？
- 直近やるストーリーの見積もりに変化はないか？
見積もりを見て再度順序を検討する（PO）
- 何かをやるためには何かを諦める必要がある
一旦スプリントから離れて、インセプションデッキを見返しながらプロダクトの方向を見直すのも良い
-
22:05 スプリントの準備 スプリントプランニングに入る前に、曖昧なストーリーはPOが明確にしておく 例えばユーザーヒアリングをして仕様を決めておく、ペーパープロトを作るなど
曖昧なままのストーリーはスプリントプランニングには入れないほうが良い 手戻りを防ぐため
-
22:08 プロダクトオーナーの仕事で難しいのは、開発したい機能の仮説をチームに伝えること
✕この機能を作ると売上が上がる ◯こういうユーザはこういうことをしたがるから、こういう機能があるとリピート率が上がる
ステークホルダー一覧を書いて、それぞれの期待を整理してみると良い
07:32 スプリントレトロスペクティブは問題解決のイベントではない
スプリントで起きた問題は都度提議し、解決する レトロスペクティブでやるのは自分たちの仕事の進め方を改善すること
-
07:41 完成の定義 これを満たしてないものはスプリントレビューではデモすることができない 例えばでも環境にリリースされていること、十分テストされていること、など
ここに含まれていないが、実際の本番リリースに必要なものはあとでリリーススプリントでやることになる
なるべく完成の定義を広く設定することで、リリーススプリントで慌てずに済む（後回しにしない）
-
07:50 スプリントプランニング
- ベロシティから着手できそうなあたりをつける（あくまで予測のため絶対ではない）
- 着手したいストーリーを明確化させる
- 不明点があれば明らかにする
- どうなれば「完成」と言えるのか確認する
- デモ手順を決めておくと実現するもののイメージがわかりやすい
- どのように実現するか、個々のタスクに分解する
- xx画面の実装
- apiの実装 など
- タスクを見積もる
- 半日で終わるタスクは3時間、など
- スプリントゴールを明確化する
順番はこうなる 第一フェーズ
- 優先順位の見直し
- スプリントゴール決定
- プロダクトバックログアイテムを選ぶ 第二フェーズ
- タスクを洗い出す
- 見積もる（時間）