プロダクトバックログについて海外の例も踏まえ考えたこと

 2009/10/02

Follow @ryuzee

Agile経験がほとんど無いチームにScrum＋XPの開発方法を教えながら開発しているのだが、 プロダクトバックログと見積もりポーカーのあたりでメンバーがもやっとしていたようなので 自分自身の整理も兼ねてメモ。

事例検証

まず以下は海外サイト等で公開されているプロダクトバックログのサンプルをいくつか見てみよう。

SimpleProductBacklog

http://agilesoftwaredevelopment.com/scrum/simple-product-backlog

気になるところ

• Sprintに入る前に「#1 CI環境を構築する」「#4 Webサーバを構築する」とかあるけど、顧客から見るとどうかな？これはSprint0のタスクであるような気がする。
• このリストはフィーチャーなのかストーリなのかが分かりにくい。Sprint1の項目はフィーチャー。Sprint2の内容はストーリに近いような。

Learning Scrum - The Product Backlog

http://www.mountaingoatsoftware.com/product-backlog

気になるところ

• やっぱりあんまり顧客向けではない
• もうちょっと分かりやすいストーリー表現が良いのではないかな？

Scrum Product BackLog on Google sites

http://www.spritle.com/blogs/?p=254

気になるところ

• 僕の好みはこれかな。誰が何する。結果として何を得る。が書かれている。
• この画像はプロダクトバックログをGoogleApps使って管理する例として出されているものなんだけど、面白いアプローチだよね。
• オンラインドキュメントなら共有は簡単だ。Excelより賢いかもしれない。

Scrum And Xp From The Trenches(塹壕よりScrumとXP)

http://www.infoq.com/jp/minibooks/scrum-xp-from-the-trenches

気になるところ

• ストーリーが若干短くてフィーチャーと混同されそうだ。もうちょっと日本語的が良いな。
• ストーリーの横にデモ方法があるけど、本来的に、ストーリーとシナリオは1:1では無いので、例としては適切では無いように思う。

じゃあどうやってバックログ書こうか？

アジャイルな見積もりと計画づくりによれば、 「ユーザストーリーは提供するフィーチャの説明であって、こなすべきタスクではない。」 とある。 顧客は自由にバックログに新しいアイテムを追加できるという価値観だから、顧客から見ると直接的な価値の無いことは載せる意味が無い。 はっきり言ってしまえば、多くの顧客にとっては、 「データベースにインデックスを沢山張る」というタスクについてはどうでもよい。 そうではなく 「利用者のリクエストは3秒以内に応答する」というストーリが実現できていれば良いだけということだ。

だからバックログは顧客の言葉で書く。これが前提。

次にプロダクトバックログには、ストーリを書く。フィーチャーだと粒度が大きすぎて、そこからストーリー→シナリオに落とさなければならないし、ストーリーが無い××機能みたいな言い方は顧客が欲しい物の内容が伝わらない可能性もある。見積もりゲームの結果もばらつきが出て収拾つかなくなるだろう。 極論すると、見積もりゲームで、1,2,3,5,8,13くらいに落ちるまで、バラしていくと良いのではないかと思っている。

参考

フィーチャーとストーリーとシナリオの違いは以下を参照すると分かりやすい。

[システム開発][Agile開発]特徴(Feature)、粗筋(Story)、脚本(Scenario)

Feature=特徴

    * 自分は今までFeatureを「機能」と紹介してきた。
    * 同じ「機能」でも開発者が対象にするのはFunctionで、利用者が対象にするのはFeatureですよ、と説明してきた。
    * でも、安井さんと角谷さんの本29頁を読むと「特徴」がいいのかな、と思った。

Story=粗筋

    * その特徴(Feature)を利用者が具体的に体験する過程を記述したのがStory。
    * AgileではこのStory単位で見積りや計画を行い、開発が進められる。
    * これは「粗筋」かな、と。
    * 理由は、この後にでてくる「Scenario」との関係で。

Scenario=脚本

    * 粗筋(Story)をより具体的に記述したもの。
    * 受入検査*4の根拠となる。

 2009/10/02

Follow @ryuzee