プロダクトバックログに技術的な項目を含めるべきか？
みなさんこんにちは。@ryuzeeです。
http://agile.dzone.com/articles/technical-stories-are-theyより抜粋翻訳してご紹介します。 なお、内容はYahooGroupのスクラムメーリングリストで議論されたもの。本文中XPに関する記載はあえて除外しています。
疑問：プロダクトバックログに技術的なストーリーを含めるべきか
スクラムでは？
Scrum.orgのスクラムガイドの説明ではこう言っている。
- 「プロダクトバックログには、製品の開発、リリースのために必要なすべての事柄を含める。プロダクトバックログは、フィーチャー、ファンクション、技術要素、機能拡張、バグフィックス等の将来の製品出荷までに行われるすべての項目を含む」
- 「スプリントバックログは、チームがプロダクトバックログアイテムを完了させるのに必要なタスクから構成される。項目の多くはスプリントプランニングミーティングで洗いだされる。スプリントバックログはスプリントゴールの到達に必要とチームが判断したすべての作業のことである」
では正しい答えは？
コンテキスト次第。
例えばあなたの完成の定義の中に、ユニットテスト、自動テスト等の項目が含まれているなら、あえてプロダクトバックログにそのような項目を載せる必要はない。 顧客と交渉の必要もないし、それで十分だ。 見積りの際には定義した内容がすべて完了する時間を見積もる必要がある。
一方、「チームメンバーとして、既存のユニットテストをCruiseControl上で動作させたい」のようなプロダクトバックログ項目はどう扱うか？ このストーリーは良く書けてはいるが、エンドユーザーにとっては最終的には直接的な価値はない。 こういう時は以下のようにすればよい。
「この手のストーリーはプロダクトバックログには含めないけど、スプリントバックログの中には含めてよいタスクだろう。 （中略）もしスプリントプランニングミーティングでタスクの分割をしているなら、この手のストーリーや作業はスプリントバックログ内のタスクとして含め、この作業に関する時間はバーンダウンチャートで追跡すれば良い。（後略）」
最後に
この手の話をどう扱ったらよいかはチームで議論して、チームとして最善の方法を決めたら良い。
上記までがまとめの内容です。以下は私見です。
私見
プロダクトオーナーが技術に精通している場合は、継続的インテグレーション環境を構築する、というプロダクトバックログ項目でも分かってくれるかもしれません。 そうでない場合は、「高生産性・高品質を維持できる開発環境を構築する」というプロダクトバックログ項目にして、そのプロダクトバックログ項目に紐づくタスクとして、「Tracを構築する、Subversionを構築する、CruiseControlを導入する、VMwareで仮想化した開発用OSを作る、全員共通用Eclipseの設定と配布を行う」みたいなタスクにする形でやることが多いです。
ただ、いずれにせよ、メーリングリストで議論されているようにチームとしてよりよい方法、やりやすい方法を考えればよいでしょう。
![サーバ/インフラエンジニア養成読本 DevOps編 [Infrastructure as Code を実践するノウハウが満載! ]](/images/common/book_devops.png)
