用户故事驱动的敏捷开发 – 2. 创建backlog

本系列的第一篇【用户故事驱动的敏捷开发 – 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