您当前的位置: （序言，之一，之二，之三）
Product Backlog到底长什么样子？
最开始看到Backlog这个词，看成Back bag（“背包”），感觉挺形象的，有一包东西挺沉的背着，看大家也画成一摞大砖头的样子，自己就照着画。比如下边这个，就是我在PPT里边用的最多的。
不过这堆砖头到了现实世界，到底什么样子？尤其是Product Backlog？考察过很多以往的产品，好像也就是一个巨大的故事列表，还真没见过除了故事列表之外的东西。
Sprint Backlog的境地好一些，至少出现个Story Board或曰故事板或曰看板，但Product Backlog就没这么好运。
故事表？
最初想的很简单，一个巨大的无始无终的表格作为Product Backlog，里边有两个字段：一个叫做优先级，一个叫做状态。用前者表征哪个故事最重要因此也最需要开发，用后者表征开发了没有。鼠标一点，按优先级进行排序，从最上面挑选最重要的，直到工作量饱和为止，就可以进行开发啦。
然而一切居然不是这个样子。
自从第一个月我们做了专门的用户故事生成页面，创建用户故事就不再是想当年一样要进入数据库手动操作的困难事情了。于是有意无意地，想到了很多有价值的故事，没头没脑地就填入系统了。
在1个人工作了短短的2个月后，故事的ID就涨到50多了。我们一般每个故事的显示要占用3行，所以一个屏幕上只能放10个故事，需要5个屏幕才能看到所有故事。
如果10个人干上12个月……300屏幕！即使只显示标题，也需要100屏幕，谁能看得清“我们产品的Backlog”？这个敏捷开发管理软件开发完了，会有人用吗？
“300屏幕的用户故事……”走在秋日街头，感觉它们就像秋日的落叶一样多……
落叶？
故事树！
《一千零一夜》中有一千零一个故事，残暴的国王本来一天杀一个新婚皇后，结果这个皇后的故事一直讲不完，结果就一直听到了最后，直到国王回心转意为止。我小时候还真的看过几乎全本的《一千零一夜》，知道其中的很多具体情况。
这1001个故事，不是讲完一个再讲一个——否则万一有一个故事不精彩，国王一瞌睡，就前功尽弃了——而是环环相扣地展开。起点是宰相女儿给国王讲述的第一个故事，然后则是故事套故事，最深的地方估计有四、五层之多。
国王不杀王后不是因为“其中一个故事没讲完”，而是就像咱们调试程序一样，正单步运行在树形的函数调用里边呐，里边的小故事是讲完了，外面的main()还没退出来，所以国王舍不得按Shift+F5，就无奈地地按了1001次F10。
这就是故事树。
所以，何不试试故事树。
这个月，产生了一个我们查阅了很多前辈产品也没有找到，但自己又不得不需要的一个视图。迄今为止，它是我最常使用的一个视图，一株枝叶下垂的故事树。
像不像？
注：传统的目录“树”只有一列，如果树的目录很多，而每个目录中又有很多内容要显示，就会变得很长，更像“藤”而非树，需要一个大大的滚动条才能看全。而实际的树之所以长成蓬松的样子，是因为总是有几个一级树干先把树的形状支撑起来，到了细枝末节，才在上面长树叶。图中的故事树就是这个样子产生的，横向是横向显示的一级目录，撑起树的整个形状；二级及以上目录则仍垂直显示。
有一个古老的问题：什么是敏捷方法？
现在似乎有了一个答案：如果第二天可能被砍头，没有时间顾及繁文缛节，又不想坐以待毙，那天晚上想出来的方法，就是敏捷方法。
附：2012-06-26 火星人实际的故事树结构
上文图大约截取自半年前的火星人，现在的火星人故事树外观如下。这是50%时截取的图片，100%时，需要滚屏一次，才能完整看到。
而这，不过是大约一个人年的研发工作量，在更大型团队和更长期开发过程中，单靠原来意义上的“故事表”的概念，是无法对产品全貌进行规划的。
之所以这个问题之前没有被太多提到，主要是敏捷开发的开始的发明者和实践者，多数是技术开发人员而非产品管理人员，也就是多数是Team而非PO，因此很少关注Product Backlog，但对Sprint Backlog的实践却很多（故事板，看板，燃尽图，MoSCoW……）。
