SCRUM BOOT CAMP THE BOOK読んだメモ
最近弊社でスクラムを取り入れるという話になり、気付いたら始まっていたので遅ればせながらスクラムについてキャッチアップしていこう運動を始めました。
手始めにSCRUM BOOT CAMP THE BOOKを読み始めたのでそのメモをば。
なお、タイトルが「読んだ」になってるけどまだ途中です。
プロダクトバックログの見積もり
開発メンバー全員で、ポーカーなどを用いて相対見積もりで数字を出していく作業。
この際重視しているのは、話し合いをすることでメンバーが対話を出来る状態になることや、目を多くして見落としをなくすことの模様。
以下、見積もり上でのポイントっぽいところ
- 作業量を相対的に見積もる
- 基準となるユーザーストーリーを一つ決め、その基準を元にストーリーポイントという単位で見積もる
- 見積もりそのものは割りとえいやでやってしまって良くて、誤差を気にするよりも手早く終わらせることを優先
- 詳細にやるのは優先度が高い、直近でやるべきユーザーストーリーに対してのみ。
- 見積もり上で疑問・不明点があり、それが解消できないと見積もれないものについては無理に数字を入れなくとも良い
スプリント計画MTG
2部構成になっており、1部でスプリントで着手するユーザーストーリーを提示、2部で作業の実現方法を話し合う。
一部
- POがプロダクトバックログから今回のスプリントで着手するユーザーストーリーを提示
- その際に要件の説明や、完了定義を説明、開発メンバーと意識合わせをする
二部
- 開発メンバー全員でタスクの洗い出しと詳細な見積もりを行う
- なるべく詳細なタスクに分割し、1タスクにどのぐらい時間がかかりそうかを見積もる
- スクラムでは計測した結果を元にした予測がキモになるので、ここでは詳細で具体的な計画にすることを心がける
デイリースクラム
ここで報告する目的はスプリントにおいての「検査」であり、進捗報告ではない
スプリント目標を達成するために、新たに問題が出ていないかを毎日検査する
- 15分を必ず守るようにする
- スクラムマスターはデイリースクラムの少し前にメンバーに声掛けするなどしてスムーズな進行を心がけると良い
- 問題発見の場であり、問題解決の場ではないので、解決のための案だしなどが始まるのはNG
- 問題が見つかったら、デイリースクラム終了後に必要なメンバーで対策の話し合いをすぐ行う
- 問題発見さえできればいいので、PO/SMはいなくても良い。
スプリントレビュー
POが完了条件を満たしているかを確認する場
- 要は認識合わせの場っぽい
- なので、動くものを見なきゃ認識あってるかわからないよね、という話になる模様
今日のところは一旦ここまで。
