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

原创 2016年05月31日 22:30:17

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

udad-2-create-backlog-01

这个样例应用可以通过以下地址访问:

http://pucd.chinacloudsites.cn/

udad-2-create-backlog-02

这是一个简单的电子商务网站原型,具备产品列表,购物车,后台管理,促销和订单处理等电子商务网站的基本功能。你可以浏览一下这个网站,对其中的功能简单了解一下。

用户故事列表


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

udad-2-create-backlog-us-01

udad-2-create-backlog-us-02

udad-2-create-backlog-us-03

udad-2-create-backlog-us-04

udad-2-create-backlog-us-05

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

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


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

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

udad-2-create-backlog-03

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

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

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

udad-2-create-backlog-04

现在我们就可以将我们的用户故事导入到TFS中,

udad-2-create-backlog-05

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

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

udad-2-create-backlog-06

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

udad-2-create-backlog-07

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

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

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

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

udad-2-create-backlog-08

至此,我们就完成了用户故事到产品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

版权声明:本文为博主原创文章,未经博主允许不得转载。 举报

相关文章推荐

怎么用leangoo做需求管理?(用户故事地图)

在介绍故事地图之前,我们先回顾一下用户故事的基本概念。用户故事是......

如何将用户故事细化为开发任务

原文出处:http://www.softwareandi.com/2011/11/how-to-break-user-story-into-tasks.html   将用户故事细化分解成开发任务是Sc...

我是如何成为一名python大咖的?

人生苦短,都说必须python,那么我分享下我是如何从小白成为Python资深开发者的吧。2014年我大学刚毕业..

用户故事地图

用户故事地图 用户故事是描述用户需求分析的一个好方法,可以将backlog变成一个二维地图,从而容易看到整个规划的全貌,帮助开发人员快速的了解客户的需求,并确定产品模块的实现优先级,实现最大用户价值...

划分用户故事(user-story)的原则

在敏捷开发过程中是通过用户故事来将需求具体化成可以进行迭代开发的一个个现实的可见的开发任务。因此在敏捷软件的开发过程中,用户故事的划分对于迭代和开发起着举足轻重的作用。 用户故事从其名字来看是站在用...
  • rxr1st
  • rxr1st
  • 2012-05-02 21:53
  • 12393

什么是用户故事地图?

为什么会有用户故事地图? 迭代开始后,待办列表总是以小块形式进入迭代开发,一个迭代接着一个迭代。碎片化的方式,不能给产品以及开发团队一个整体的视觉。这会出现,优先级排列问题,或者产生多个迭代后,用户还...

用户故事地图对应到Epic及其缺点

用户故事地图,提供了2维的角度来分析用户故事,直观,更加有利于优先级的表达。 在理解用户故事地图时,需要注意其作者的用词跟一般的用户故事不一致,因此要注意跟普通的用户故事用词之间的对应关系。 推荐...

使用Leangoo玩转故事地图

通过leangoo看板,我们可以非常方便的通过故事地图把产品的需求全景图展示出来,产品的规划也一目了然,这对于我们持续地关注产品核心价值,更好地进行产品规划非常有帮助。

如何捕捉用户故事(2)--story&process/Themes mapping

在Cruise项目使用了Story&Process/Themes Mapping的方法来检查Story list是否有遗漏。操作起来也非常简单。其步骤是: 一、将所有业务流程画在一个大白板上;(画不下...

敏捷开发中用户故事地图(User Story Mapping)学习

1.用户故事地图         User Story是敏捷开发和管理的核心,User Story是从用户的角度对系统的某个功能模块所作的简短描述。一个User Story描述了项目中的一个小功能,...

用户故事驱动的敏捷开发 – 1. 规划篇

敏捷开发现在已经不是新鲜事物了,我们都从各种渠道听到过不同的团队实施敏捷的胜果,听的时候觉得很美,回到家就发现那都是别人家的团队,结合自己的情况一看就发现问题一大堆。就算是最终打算一试,也经常会不知如...
  • ups216
  • ups216
  • 2016-05-31 22:28
  • 8392
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)