「アジャイルソフトウェアエンジニアリング」におけるプロダクトバックログの考え方

「アジャイルソフトウェアエンジニアリング」が発売されるらしいのでリンクしておく。
サンプルとして9章がフリーで読める。

【元ネタ】
『アジャイルソフトウェアエンジニアリング』発行記念 | 日経BP社 ブックス＆テキスト Online

[書籍] アジャイルソフトウェアエンジニアリング | 長沢智治のブログ | 一伝入魂

「アジャイルソフトウェアエンジニアリング」という本が出版されます - かおるんTFSダイアリー

「アジャイルソフトウェアエンジニアリング」はMicrosoftのTFSを題材とした本。
MSのようにソフトウェア開発にとても経験のある企業でさえも、Conwayの法則から逃れられないという経験則は興味深い。

サンプルの9章を読んで興味深かった点は、プロダクトバックログの作成方法だ。
それ以外のアジャイルな考え方は、多分普通だろうと思う。

MSでもフィーチャ(機能)を基本として、フィーチャをタスクに分割してソフトウェアを開発する。
その弱点は、知らないうちに過剰生産してしまうこと。
つまり、無駄に機能が増えて使いづらいUIになったりする危険があること。
リーンソフトウェア開発でも言われているように、製品の過半数の機能はユーザが使い方を知らない機能ばかりになって複雑化してしまう。

そこで、フィーチャに階層構造を導入して、開発者の観点だけでなく顧客やビジネスの観点も入れるようにした方法が書かれている。
上記では、シナリオ＞エクスペリエンス＞フィーチャという階層構造でまとめる。
シナリオは、製品を使った場合に具体的な顧客価値を定義する。「もし○ができたら購入したい」というイメージ。
エクスペリエンスは、開発者が顧客へ具体的な価値を提案する。「○のやり方を教えましょうか」というイメージ。
フィーチャは、ユーザストーリーないし実際の機能。

「アジャイルな見積りと計画づくり」にあるエピック＞テーマ＞ストーリーの概念と上記のシナリオ＞エクスペリエンス＞フィーチャは1対1に対応するように作られているらしい。
MSがアレンジしているのは、シナリオに「基本項目」「顧客の不満因子の除去」というカテゴリも入れていること。

基本属性シナリオの例として、互換性、信頼性、パフォーマンス、グローバル対応などが挙げられているが、これは品質特性を意味しているのだろう。
つまり、顧客にとって価値ある機能は目に見える使い勝手だけではなく、製品全体を貫く品質特性(信頼性、可用性など)も当然含まれるわけだ。

顧客の不満因子の除去シナリオの例として、優先順位の低いバグや小さい便利なフィーチャを指している。
わざわざ顧客の不満因子の除去というシナリオを作っている理由は、これらのフィーチャは個別にトリアージした場合通常は修正対象外となるが、積もり積もれば大きな障害やユーザ離れの原因になるので、一つのシナリオにまとめて、他のシナリオと同じレベルで優先順位付けできるようにしたいから。
このやり方は、要件のトリアージで見落としがちな顧客価値を敗者復活戦で復活させる重要な仕組みなのだろう。
そういう意味では、MSはプロダクトバックログの良さと悪さを十分に経験しているように思える。

TFSは個人ではとても購入できるツールではないが、その考え方はチケット駆動開発にも適用できる。
チケットをストーリーカードに対応付けて、エピック＞テーマ＞ストーリーの階層構造を親子チケットで表現して、それぞれの階層で観点を使い分ければいい。
PivotalTrackerやFulcrumのようなストーリー駆動のタスク管理ツールと併用すれば、より面白いかもしれない。

「アジャイルソフトウェアエンジニアリング」は良い本のような気がする。