「塹壕よりScrumとXP」読書メモ (1)
こんど Henrik さんの CSM を受講するので「塹壕よりScrumとXP」をちゃんと読んだ。
はじめに
- Scrum はフレームワーク。どうやるかまでは教えてくれない。これはぼくの戦争体験談だ (!!)
プロダクトバックログ
スプリント計画ミーティング
- スコープ、重要度、見積もりという3つの変数について話しあう場
- POが参加してくれない問題をどう解決する?
- わかりやすく説明して説得する
- 代理人をたてる
- 参加できるまで延期する
- 内部品質と外部品質
- 外部品質はユーザにわかるもの。使いやすさ、操作性の良さなど
- 内部品質はユーザには見えない。コードの質、テスト結果など
- 外部品質はスコープとして扱える(=交渉できる)が、内部品質はできない
- スコープとして扱うと、保守性が下がり、かえってコストが高くなる
- 例:「これ応急処置でやっちゃおう」
- POはこのことを学習してくれる
- ミーティングは短く終わらす。タイムボックスをからだで覚える
- スプリントの最適な長さはいろいろ試して決める
- 決まったら固定する
- 著者のチームでは3週間だった
- 長さが決まると快適になってくる。リリース日についても悩まない
- スプリントのゴールを決めるのはむずかしい
- でも、ないよりはまし
- 「どうしてこのスプリントを実施しているのか?」をつねに考える
- プロダクトバックログ→スプリントバックログ への移動
- ストーリーの大きさでスプリント中にやれる事が決まる
- だから相対見積もりがだいじ
- スプリントに含めるストーリーが何かはチームが決める
- POではない
- 含まれたストーリーが不服な場合、POは他のストーリーのスコープを変えたり、分割したりして調整できる
- (外部品質を別ストーリーに移したりってこともあるな)
- (ここが一番「これ応急処置でやっちゃおう」になりそうなので気を付けないと)
- 見積もりはどうやるか
- 小さいチームなら直感で決められる
- 見積速度:1スプリントで完了したストーリーの大きさ
- 稼働人日×フォーカスファクタ=見積速度
- フォーカスファクタは前のスプリントを参考にして求められる
- コンピュータ上でストーリーの洗い出しをやっていると、問題点に気づきづらい
- PCをいじってる人以外は、自分が参加してるという意識を持ちづらくなる
- だからインデックスカードを使うお!!
- ストーリーごとに完了の定義をきめるのはだいじ
- 厳密なチェックリストより、直感を重視する
- プランニングポーカー
- チーム全員がストーリーを理解するのを助ける
- 相互協力できるようになる
- ストーリーを明確にする
- ストーリーに対する誤解を避けるには、ぜんぶのストーリーについてちゃんと(POのいる場で)話し合う
- (わかったふりして飛ばすとそこで躓くのは、よくありますね…)
- ストーリーが小さすぎたり、大きすぎるときは要注意
- タスク分割はWF的に感じられる場合もある?
- Techストーリーについて
- 直接顧客への価値にむすびつかないけど、やらないといけないこと。例えばCIサーバの構築とか
- 通常のストーリーに組み入れられないか検討してみる
- 無理そうならTechストーリーを作成。(POは編集できない)
- Techストーリーの実施によってどのようなメリットがあるのか、POにきちんと説明する
- POがTechストーリーの重要度を理解できるなら、判断してもらうのがベスト
うーん、盛りだくさんだー。(つづく)