本系列的第一篇【用户故事驱动的敏捷开发 – 1. 规划篇】跟大家分享了如何使用用户故事来帮助团队创建需求的过程，在这一篇中，我们来看看如何使用这些用户故事和功能点形成产品backlog。产品backlog是敏捷开发中用来管理需求列表，排定优先级，形成迭代计划，组织开发/测试和交付过程的工具。可以说，产品backlog是一个敏捷团队管理开发过程的核心，所有的活动和交付物都围绕backlog来进行。一旦需求明确，我们就必须在开发过程中持续的跟踪backlog内容的实现和交付过程，确保我们的想法可以按照我们希望的时间和质量交付，及时了解偏差并做出调整。
从这个时间点开始，我们需要引入电子化工具来管理我们的开发过程。其实，每个开发团队都会或多或少的使用某种电子化工具，用最多的估计是Word/Excel/Project这种办公软件，还有就是如Jira, Redmine, Bugzilla 等工具。对于软件研发来说，我们需要管理内容包括：1）需求/任务/测试用例/Bug/问题等工作事项；2）源代码；3）各种计划，包括迭代计划，发布计划，测试计划等；4）各种工件（包括：依赖包/在制品/交付物），如：JAR包，WAR包，NuGet包，NPM包，安装包，交付包等；5）人员/团队。所以，对于软件研发管理系统来说，我们至少需要这些功能：1）工作项跟踪；2）计划制定和跟踪；3）人员（包括权限）管理；4）源代码管理；5）自动化引擎。
很多敏捷教练其实对电子化工具持保留态度，觉得电子化的backlog或者kanban等工具会影响团队的参与感和灵活性。对这一点，我也同意，特别是在进行创造的过程中，我也不赞成使用电子化工具。主要原因是创造的过程需要集思广益，需要每个团队成员都有参与感，需要每个人可以随时对于用户故事做出改变，这样的过程如果使用电子化工具会很受限制。
但是，电子化工具仍然有其不可替代的用武之地，特别是我们需要进行持续的跟踪和数据分析的时候，电子化工具就显示出它的优势；同时，如果你的团队分布在不同的物理地点，那么使用电子化工具就成为一种必然。因为这些场景都是物理板无法发挥作用的时候。另外，考虑到软件开发过程的复杂性和各个部分只见关联性很强，如果没有电子化工具的辅助，是很难支撑一个团队的开发工作的。
在我带领团队使用用户故事地图的过程中，随着用户故事数量的增加，我发现团队开始迷失功能点与故事之间关联性，分解出来的功能点被淹没在不同的模块之中了，用户故事已经开始慢慢消失了。这是个非常不好兆头，所以我在这个时候开始要求团队引入电子化工具。
样例程序和用户故事列表
为了能够更好的说明这个过程，在这个系列中我使用【凤凰项目：一个IT运维的传奇故事】这本书为背景的ASP.NET 5样例应用，创建了一些用户故事
关于【凤凰项目：一个IT运维的传奇故事】：本书讲述了一位IT经理临危受命，在未来董事的帮助和自己“三步工作法”理念的支撑下，最终挽救了一家具有悠久历史的汽车配件制造商的故事。 小说揭示了管理现代IT组织与管理传统工厂的共通之处，让读者不仅能对如何管理IT组织心领神会，更重要的是将以完全不同于以往的视角看待自己的工作环境。
可以通过以下链接购买这本书的中文版：http://item.jd.com/10034038960.html
这个样例应用可以通过以下地址访问：
http://pucd.chinacloudsites.cn/
这是一个简单的电子商务网站原型，具备产品列表，购物车，后台管理，促销和订单处理等电子商务网站的基本功能。你可以浏览一下这个网站，对其中的功能简单了解一下。
用户故事列表
以下是我使用影响地图和用户故事地图整理出来的故事列表，每张图片的左侧是影响地图，列出一个故事；右侧是这个故事所分解出来的功能点摆放在用户故事地图上的的效果。
上面5个用户故事所分解出来的功能点我分别使用不同颜色在故事地图上进行了标注，你可以看到当故事不停增加的时候，这个地图会慢慢变得非常庞大而繁杂，分辨出用户故事变得越来越难。
使用Team Foundation Server来管理用户故事
Team Foundation Server (TFS) 是微软公司的研发管理平台，其中提供了从需求管理，项目管理，配置（源代码）管理，测试管理，代码编译持续集成，自动化测试，自动化发布及部署环境管理在内的研发运维一体化（DevOps）的完整工具链。微软自己的大多数产品都在使用这个平台进行研发管理，其中也对敏捷开发提供了很好的支持。
在整理用户故事的过程中，我们可以先使用Excel来记录这些用户故事和功能点，同时记录每个功能点所属的功能区域，形成类似以下的文档。
以上表格中，我们用二维表的方式保存了用户故事地图上的所有关键信息，在导入到TFS的时候需要注意：
- 故事地图实际上是一个二维表格，顶部的功能区域/模块部分是功能点的分类，这部分内容可以使用TFS所自带的 区域路径 来进行表达
- 每个故事（左侧的WHY-WHO-HOW/WHAT），与右侧的功能点之间是一种父子的一对多关系，可以用TFS backlog中的不同级别的工作项所代表，TFS可以维护不同级别工作项之间的父子关系，正好可以跟踪这部分信息
- 右侧的每个卡片对应到这个二维表顶部的特定的功能区域/模块，我们在导入的时候只要设置每个工作项的 区域路径 字段的值，完成这种对应信息的跟踪
首先，在TFS中按照功能区域和模块创建区域路径，对应到用户故事地图顶部的分类信息
现在我们就可以将我们的用户故事导入到TFS中，
关于如何使用Excel批量导入和更新工作项，请参考：https://msdn.microsoft.com/en-us/library/vs/alm/work/office/bulk-add-modify-work-items-excel
形成的backlog如下，你可以看到TFS很好的维护了我们的用户故事到功能点之间的联系，同时也保留了每个功能点所对应的功能区域，这样就把用户故事地图上的关键数据进行了很好的维护，便于我们从不同的角度来查看和跟踪。
导入的工作项用不同的字段保留了用户故事地图上的关键信息：
当然，你仍然需要对每个用户故事工作项和功能点工作项进行进一步完善，将团队在讨论过程中所产出的信息进行记录，比如：每个用户故事需要包括用户背景，操作流程图，交互设计原型；每个功能点需要包括数据字典，输入输出，数据验证，界面原型等。这些内容可以直接填写在工作项的 说明 字段，或者使用附件的形式上传到工作项上统一保存。
在规划篇中，我强调过用户故事所注重的是它所驱动的过程，而不是那份文档。但是，我们仍然需要将团队讨论中所产生的关键信息进行详细的记录，这样便于团队在后续的开发中回忆起讨论的细节。这些信息在看板或者白板这种物理工具上是无法表达和保存的，所以这个时候引入电子化工具恰到好处。
我们所导入的故事和功能点将构成后续开发所使用的backlog，便于团队对这些内容进行优先级排序，迭代规划，任务分解，测试计划的制定，测试用例的分解等等。也就是说，后续的软件研发过程均会按照我们导入的backlog作为主线进行。这样，团队既可以按照用户的角度来抽取出相应的功能点，也可以从产品模块的角度查看功能列表和影响这些模块的用户需求，保证团队在满足用户需求与架构优化演进之间做出取舍，为团队建立起完整的需求跟踪视图（有很多团队会称之为需求跟踪矩阵）。
见下图，我们之前所做的其实就是建立的图中的 架构模型 和 条目化需求 部分的内容，同时在这两部分内容之间建立的联系，这些是建立一个软件研发管理系统的源头。
至此，我们就完成了用户故事到产品backlog的转化，下一篇中将介绍如何完成开发和测试计划的制定，并开始引入Kanban来跟踪开发过程。
注：以上场景是【DevOps敏捷开发动手实验】的一部分，请点击以下链接访问这个动手实验的指导文档：
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