｢塹壕より Scrum と XP｣を読んだ

早速塹壕より Scrum と XPを読んだので自分なりのまとめ。

言葉

• プロダクトオーナー
  • 要求と優先度について唯一権限を持った人
• プロダクトバックログ
  • 優先順位付けされた要求、利用ストーリー、機能リスト
  • 顧客の望む事柄が、顧客の言葉で書かれている
  • ID、名称、重要度、初期見積もり、デモ方法、備考を含む
  • プロダクトバックログはビジネスレベルを保つ
    • ｢何をするか(What)｣であって｢どのようにするか(How)｣ではない
• スプリント
  • 繰り返す開発の単位（３週間がいいらしい）
  • 各スプリントの成果物としてリリース可能なソフトウェアがあること
• スプリントバックログ
  • スプリントで作成する成果物
  • プロダクトバックログから選択する
• スプリントプランニング
  • スプリント開始前に行う
  • スプリントのゴールを決める
  • スプリントバックログを決める
  • 確定されたスプリントデモの実施日を伝える
  • 確定された日次スクラムの場所と時間を伝える
• スプリントデモ
  • スプリントでの成果物をプロダクトオーナーに見せる
  • 日次スクラム
  • 毎日決まった時間（主に朝）に行うミーティング
  • 今日やることや今の状況を共有する

スプリントでの見積もり

• バックログでの各ストーリー（機能）に｢ストーリーポイント｣という単位を振る
• ストーリーポイントは｢人日｣とする。人時だと細かくなりすぎる
• ｢稼動人日×フォーカスファクタ｣をスプリントで消化できストーリーポイントの総数とする
  • フォーカスファクタは 70% くらいが適切

計画ポーカー

• 各ストーリーの時間見積もりはメンバーみんなで行う

スプリントデモのチェックリスト

• スプリントのゴールを明確にする
• デモの準備に時間裂かないようにする
• 手際よくプレゼンテーションを行う
• ビジネス指向のデモを保ち、技術的な詳細は扱わないようにする
• 聴衆自身に成果物を試してもらう
• 些細な機能やバグフィックスは扱わない

スプリント間の休憩

• スプリントとスプリントの間に休憩時間を設ける
• 情報や考えを整理したり教訓を得たりする時間を設ける

スプリントで前回のスプリントの不具合がでたら

• 新しい機能に着手してよいが、未完成の古い機能を優先する
• 新しい機能に集中することは避ける（最後に中途半端で使えないものができあがる）

コードブランチ（SCMの話）

• trunk はいつ、いかなるときもリリースできる状態であるべき
• 各リリースにタグをつける
• ブランチを使うのは異なるライフサイクルを扱うとき
• ブランチで作業してる場合は、毎日メインラインから自身のブランチにマージすること（ちゃんと同期してね！）

まとめ

がっと読んだので頭の中が｢？？｣だけど、少しずつ解消していこうと思う。
でもおかげでこの前の勉強会でのえばっきさーんのスライドの意味がやっと理解できた＾＾；
ところで、文中に出てくる｢塹壕より TDD｣は訳されてない？？

参考

• ebacky way