本系列的第1篇【用户故事驱动的敏捷开发 – 1. 计划篇】跟大家分享了如何使用用户故事来帮助团队创建需求的进程，在这1篇中，我们来看看如何使用这些用户故事和功能点构成产品backlog。产品backlog是敏捷开发中用来管理需求列表，排定优先级，构成迭代计划，组织开发/测试和交付进程的工具。可以说，产品backlog是1个敏捷团队管理开发进程的核心，所有的活动和交付物都围绕backlog来进行。1旦需求明确，我们就必须在开发进程中延续的跟踪backlog内容的实现和交付进程，确保我们的想法可以依照我们希望的时间和质量交付，及时了解偏差并做出调剂。

从这个时间点开始，我们需要引入电子化工具来管理我们的开发进程。其实，每一个开发团队都会或多或少的使用某种电子化工具，用最多的估计是Word/Excel/Project这类办公软件，还有就是如Jira, Redmine, Bugzilla 等工具。对软件研发来讲，我们需要管理内容包括：1）需求/任务/测试用例/Bug/问题等工作事项；2）源代码；3）各种计划，包括迭代计划，发布计划，测试计划等；4）各种工件（包括：依赖包/在制品/交付物），如：JAR包，WAR包，NuGet包，NPM包，安装包，交付包等；5）人员/团队。所以，对软件研发管理系统来讲，我们最少需要这些功能：1）工作项跟踪；2）计划制定和跟踪；3）人员（包括权限）管理；4）源代码管理；5）自动化引擎。

很多敏捷教练其实对电子化工具持保存态度，觉得电子化的backlog或kanban等工具会影响团队的参与感和灵活性。对这1点，我也同意，特别是在进行创造的进程中，我也不同意使用电子化工具。主要缘由是创造的进程需要群策群力，需要每一个团队成员都有参与感，需要每一个人可以随时对用户故事做出改变，这样的进程如果使用电子化工具会很受限制。

但是，电子化工具依然有其不可替换的用武之地，特别是我们需要进行延续的跟踪和数据分析的时候，电子化工具就显示出它的优势；同时，如果你的团队散布在不同的物理地点，那末使用电子化工具就成为1种必定。由于这些场景都是物理板没法发挥作用的时候。另外，斟酌到软件开发进程的复杂性和各个部份只见关联性很强，如果没有电子化工具的辅助，是很难支持1个团队的开发工作的。

在我带领团队使用用户故事地图的进程中，随着用户故事数量的增加，我发现团队开始迷失功能点与故事之间关联性，分解出来的功能点被淹没在不同的模块当中了，用户故事已开始渐渐消失了。这是个非常不好兆头，所以我在这个时候开始要求团队引入电子化工具。

样例程序和用户故事列表

为了能够更好的说明这个进程，在这个系列中我使用【凤凰项目：1个IT运维的传奇故事】这本书为背景的ASP.NET 5样例利用，创建了1些用户故事

关于【凤凰项目：1个IT运维的传奇故事】：本书讲述了1位IT经理临危受命，在未来董事的帮助和自己“3步工作法”理念的支持下，终究挽救了1家具有悠久历史的汽车配件制造商的故事。 小说揭露了管理现代IT组织与管理传统工厂的共通的地方，让读者不但能对如何管理IT组织心照不宣，更重要的是将以完全不同于以往的视角看待自己的工作环境。

可以通过以下链接购买这本书的中文版：http://item.jd.com/10034038960.html 

这个样例利用可以通过以下地址访问：

http://pucd.chinacloudsites.cn/

这是1个简单的电子商务网站原型，具有产品列表，购物车，后台管理，促销和定单处理等电子商务网站的基本功能。你可以阅读1下这个网站，对其中的功能简单了解1下。

用户故事列表

以下是我使用影响地图和用户故事地图整理出来的故事列表，每张图片的左边是影响地图，列出1个故事；右边是这个故事所分解出来的功能点摆放在用户故事地图上的的效果。

上面5个用户故事所分解出来的功能点我分别使用不同色彩在故事地图上进行了标注，你可以看到当故事不停增加的时候，这个地图会渐渐变得非常庞大而复杂，分辨出用户故事变得愈来愈难。

使用Team Foundation Server来管理用户故事

Team Foundation Server (TFS) 是微软公司的研发管理平台，其中提供了从需求管理，项目管理，配置（源代码）管理，测试管理，代码编译延续集成，自动化测试，自动化发布及部署环境管理在内的研发运维1体化（DevOps）的完全工具链。微软自己的大多数产品都在使用这个平台进行研发管理，其中也对敏捷开发提供了很好的支持。

在整理用户故事的进程中，我们可以先使用Excel来记录这些用户故事和功能点，同时记录每一个功能点所属的功能区域，构成类似以下的文档。

以上表格中，我们用2维表的方式保存了用户故事地图上的所有关键信息，在导入到TFS的时候需要注意：

• 故事地图实际上是1个2维表格，顶部的功能区域/模块部份是功能点的分类，这部份内容可使用TFS所自带的 区域路径 来进行表达
• 每一个故事（左边的WHY-WHO-HOW/WHAT），与右边的功能点之间是1种父子的1对多关系，可以用TFS backlog中的不同级别的工作项所代表，TFS可以保护不同级别工作项之间的父子关系，正好可以跟踪这部份信息
• 右边的每一个卡片对应到这个2维表顶部的特定的功能区域/模块，我们在导入的时候只要设置每一个工作项的 区域路径 字段的值，完成这类对应信息的跟踪

首先，在TFS中依照功能区域和模块创建区域路径，对应到用户故事地图顶部的分类信息

现在我们就能够将我们的用户故事导入到TFS中，

关于如何使用Excel批量导入和更新工作项，请参考：https://msdn.microsoft.com/en-us/library/vs/alm/work/office/bulk-add-modify-work-items-excel

构成的backlog以下，你可以看到TFS很好的保护了我们的用户故事到功能点之间的联系，同时也保存了每一个功能点所对应的功能区域，这样就把用户故事地图上的关键数据进行了很好的保护，便于我们从不同的角度来查看和跟踪。

导入的工作项用不同的字段保存了用户故事地图上的关键信息：

固然，你依然需要对每一个用户故事工作项和功能点工作项进行进1步完善，将团队在讨论进程中所产出的信息进行记录，比如：每一个用户故事需要包括用户背景，操作流程图，交互设计原型；每一个功能点需要包括数据字典，输入输出，数据验证，界面原型等。这些内容可以直接填写在工作项的 说明 字段，或使用附件的情势上传到工作项上统1保存。

在计划篇中，我强调过用户故事所重视的是它所驱动的进程，而不是那份文档。但是，我们依然需要将团队讨论中所产生的关键信息进行详细的记录，这样便于团队在后续的开发中回想起讨论的细节。这些信息在看板或白板这类物理工具上是没法表达和保存的，所以这个时候引入电子化工具恰到好处。

我们所导入的故事和功能点将构成后续开发所使用的backlog，便于团队对这些内容进行优先级排序，迭代计划，任务分解，测试计划的制定，测试用例的分解等等。也就是说，后续的软件研发进程均会依照我们导入的backlog作为主线进行。这样，团队既可以依照用户的角度来抽取出相应的功能点，也能够从产品模块的角度查看功能列表和影响这些模块的用户需求，保证团队在满足用户需求与架构优化演进之间做出取舍，为团队建立起完全的需求跟踪视图（有很多团队会称之为需求跟踪矩阵）。

见下图，我们之前所做的其实就是建立的图中的 架构模型 和 条目化需求 部份的内容，同时在这两部份内容之间建立的联系，这些是建立1个软件研发管理系统的源头。

至此，我们就完成了用户故事到产品backlog的转化，下1篇中将介绍如何完成开发和测试计划的制定，并开始引入Kanban来跟踪开发进程。

注：以上场景是【DevOps敏捷开发动手实验】的1部份，请点击以下链接访问这个动手实验的指点文档：
http://vsalm-hols.readthedocs.org/

参考资料：

有关用户故事地图：
http://devopshub.cn/2016/01/10/user-story-mapping-for-the-first-time/
http://devopshub.cn/2016/01/11/how-to-create-user-story-mapping/

有关Team Foundation Server:
http://vsalm-hols.readthedocs.org/zh_CN/latest/concepts/about-vsalm.html