「塹壕よりScrumとXP」読書メモ (1)

こんど Henrik さんの CSM を受講するので「塹壕よりScrumとXP」をちゃんと読んだ。

はじめに

  • Scrum はフレームワーク。どうやるかまでは教えてくれない。これはぼくの戦争体験談だ (!!)

プロダクトバックログ

  • 実現したいストーリーの集まり。Scrum でいちばん重要なもの
  • 重要度は一意になるようにつける。あとでPOがソートできるから
  • PO (顧客) の言葉でわかるように書くことがだいじ
    • (俺は実装するだけだから、みたいな人ばかりだと無理ってことかな)
  • PO が重要度を決め、チームが見積もりを出す。逆はやっちゃだめ
  • Excelが顧客にやさしいときもある。ツールの選択は柔軟に

スプリント計画ミーティング

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

うーん、盛りだくさんだー。(つづく)