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