《软件需求管理一大工具》-管理学论文，营销论文-论文范文参考-科学狗论文网

标题

软件需求管理一大工具

范文

摘要：当前传统瀑布式项目管理方法中的需求管理模式针对软件类项目存在着一定的弊端导致项目失败的风险增大。如何利用用户故事地图的方法来有效的避免传统需求管理中的疏漏，对用户故事地图进行了简介，总结了用户故事地图的优势以及关键点。

关键词：用户故事地图;需求管理

引言

通常在一个瀑布模型的项目管理过程中，会产生如（图1）所述的项目工作流。在项目运行初期，用户会面临一个问题，他们只会参与到撰写需求以及最终测试的这两个阶段中。但是在需求文档制作完成之后直到最后的测试阶段之前，用户一般不会了解整个项目的运作情况和实施进度。无疑这将会在软件开发工程项目中增加了项目（如用户需求的演进变更史，项目经理的统筹协调，开发工作者对用户需求的实际理解程度不一等等）不成功的风险。

而在设计思维一整套方法论体系中，利用用户故事地图工具能较大程度优化项目进展阶段中碰到的问题，规避安全隐患，加强协作体系中可靠性，从而显著提升各工作环节的进度及完成质量。

什么是用户故事？

用户故事地图是设计思维的其中一个实用工具。在20世纪90年代末，Kent Beck先生在开发软件的过程中发现，最大的困扰就是如何使用文档来精确的记录客户想要的东西。传统行业中有很多人采取在需求文档上各自签字的方式来证明互相已经达成了共识，然而同样一份文档，阅读的人不同，各自得到的信息可能并不一致。

心理学家Jerome Bruner发现，用讲故事的方式来陈述事实，给人留下的印象在深刻程度上高出单独陈述事实的22倍。用户故事的核心思想即是用一种非正式的文档记录方式，最自然易懂的语言来描述实际想要实现的功能或要求。以客户或者用户的观点撰写下有价值的功能和框架等来帮助项目中不同各方对需求更好的理解。在这个基础上，可以更好的利用用户故事地图对项目进行评估筹算，制定发布计划，最终推动整个项目顺利交付。

用户故事的三个关键点：

卡片（Card）

用户在一堆card上写下对产品的期望功能和特性。card上的内容只需要让多数人一看即懂得描述的是什么（也就是自然语言而非技术性语言），易于识别需求。还可以备注一些该card所需要消耗的人力，优先级，项目成本等信息。

对话（Conversation）

用户故事的重点就是从文档转移到对话形的沟通。尽量聚集开发团队和用户一起对需要的产品进行深入讨论。多交流不同的观点、想法和感受。在对话的过程中，说的人和听的人通过反反复复的提问以及回答来修正对事情的理解，从而最终达成一致。

确认（Confirmation）

对验收条件进行分段确认。发布计划时包含了每一阶段的验收测试的标准，当故事被开发完成时，程序开发团队向客户按照验收标准进行产品功能展示或按场景进行系统试运行来确认用户所提出的需求。在完成工作成果并按阶段完成客户的需求后方能开展并执行下一阶段故事的开发工作，其中确认环节是生命周期不斷循环的关键。

创建用户故事地图的方法

在创建用户故事地图之前，首先必须确定项目的最终目标。采取最简单的填空的方法组织成尽量简单的一段话。这样可以更好的帮助清晰的认识目标，量化目标结果的实际价值以及达成目标前所需的准备工作。我们把这句话称之为“问题零”，是设计思维方法论体系中的一部分。这句话可以涵盖以下问题，但并不要求每一项都要囊括进去。

-是什么？比如做一个App？网站？还是小程序等等;

-为了什么？解决什么问题？比如供应链管理，客户关系管理等等;

-在哪里？

-谁？对象是读者？学生等等;

-用什么方法？例如Java？或者Phython等等;

接下来，为了明确需求，我们正式开始创建用户故事地图。

1.聚集具备项目背景技能或行业背景相关的不同岗位的人员，带着“问题零”让大家围绕之进行头脑风暴;

2.对目标用户进行用户特征的归纳以及归类，讨论设定用户画像;

3.用卡片记录下零散的可以想到的不同用户需要执行的不同任务，通俗说法就是用户需要执行的操作或者动作;

4.接着就是对所有碎片的任务卡片进行分类汇总，然后给每一组命名;

5.然后对分好组的卡片以组为单位按照动作执行的先后顺序排序（当然其中可能存在平行时间执行的任务）;

6.对于整理完的所有任务进行一个整体的回顾，以故事叙述的形式来检查是否存在疏漏，并对发现的疏漏或者矛盾处进行补充修改;

7.最后综合讨论每一个任务开发所需要完成的单位时间，这个过程需要取得项目中不同参与人员的一致认同或综合平均，并不一定要做到精准。

至此，一个完整的用户故事一句完成了。并可以以此为依据结合讨论各个任务的优先级，开始定制项目的发布计划，此时可以用到甘特图来制作发布计划。

某公司的信息部门准备为全球的IT相关内部人员建立一套全新的知识管理系统KMS。项目经理决定用设计思维的思路，基于注重用户体验的原则，采用用户故事地图的方法来搜集用户的真正需求。

首先，项目团队内部定义了“问题零”。项目的目的是创建一个知识分享平台解决公司内部各信息部门间信息不对等，传递速度慢的问题。使得所有信息工作者可以更快的在平台内找到最准确的信息帮助其工作。

项目团队召集了信息部门代表不同role的关键用户代表，召开了一场头脑风暴，所有与会者从自身出发列出平时工作中需要KMS帮助到他的内容，并写在了便签纸上。这些人包括技术支持人员，开发人员（非本项目组），内部宣传人员，IT管理人员，其他利用信息知识的项目管理人员，以及此项目组的相关人员等。很快就得到了满墙的小便签。

然而此时得到的所有标签都是零散的。比如IT服务热线的一线接线员希望搜索关键字就出现按照热门程度排序的解决方案。而内部产品管理团队希望可以在知识库内容有更新的时候无效的信息自动下架。服务器维护团队则希望可以把第一手的故障信息以及影响的范围发布到可以让所有内部IT人员马上看到的平台上。整个团队不断对这些零散需求的归类，得到一张任务组的清单，以及一些特定用户的形象描述。

统计汇总出来的任务组也包括发布内容，共享内容，评论内容，搜索内容，推送内容。需要注意，此时的需求并没有讲到我们需要怎么样的数据结构来建立数据库这类更专业性的需求描述，而是更商业化的需求描述語言。

接下来，团队模拟三个典型性用户使用KMS的过程，回顾他们作为用户对该系统的每个touch point，看看是否有遗漏的内容或者去掉不是特别必要的card。到这个阶段，用户故事差不多已经说完了。

在可以制定发布项目计划前，项目组还需要对完成这些card功能开发的工作量来进行估算。参与到估算讨论的有项目开发人员，项目管理人员以及关键用户。每个card的估算工作量都需要得到与会者的一致认同。比如对同一个动作需要的开发，有的人可能会觉得要测试这个，我们需要建一个模拟库对象需要1天，而且还不确定标准算法是否能用，可能需要重编一个占用内存更少的算法。这样就需要花更多的时间。而同时另一个人认为我只需要把信息存在一个XML文件中，就比数据库简单许多。这两个人的估算值肯定不会一致。如果存在疑议，大家把自己的理解说出来之后进行简短的讨论，一般在进行过2轮讨论后都会达成一致的估值。

自此，我们已经对需要完成所有的任务需要花费多少的人天有了一个大概的概念，项目经理便可以在根据这个估值以及各个功能的优先级来编辑发布计划。

简单而言，用户故事地图就是把设定的目标拆分成可执行的动作，经过归类之后形成任务组，再经过排序做成故事的一个过程。

在项目进行的过程中，card优先级可以在每一轮迭代开始前重新排序，并可以随着项目的进行增加新的或者去除不再有意义的一些card。也可以对完成开发每个任务所需要花费的时间以及人力成本估算进行调整。用户故事不是一个一旦定下便很难做修改的需求定义书。制作用户故事地图时需要注意以下几个问题：

-尽量使用更为实践性质的商业语言而不是技术语言，避免编写出针对开发人员更有价值的用户故事;

-尽量避免分散的故事与故事之间相互关联，如必要，就尝试合并相互关联的故事，或者换一个角度去拆分故事从而切断依赖;

-零散太小的故事可以合并不分类;

-尽量避免过早涉及对用户界面的描述;

-需要针对card编写测试从而确保系统没有违反约束，由于代码变化很快，尽量做到自动化测试率大于99%从而增加测试效率。

利用用户故事地图的优势

用户故事地图被用在项目准备阶段，用来更好的帮助项目团队梳理零碎细散的用户需求，方便看到一个概况。从而可以便于筛选和制定不同任务的优先级，帮助项目经理做出决策，框定整体项目范围。其中很重要的一点，在制作用户故事地图的过程中，可以更好的帮助项目团队中处于不同角色的成员都对项目的整体需求和概况有一个一致的理解。

创建用户故事地图的目标很简单，搞清楚用户到底是谁，他们要达成什么样的目标，如何达成目标。

相较于传统的需求管理，使用用户故事的项目会有不同的感觉和节奏。不使用传统需求文档而是通过用户故事card来整理的一个很大的特点就是客户需要参与项目的整个过程。需求文档的语言存在不准确性，不同角色的人阅读同一篇需求文档会产生不同程度理解上的偏差，导致真正的需求极易被误解。而故事驱动的需求管理能很好的避免不同项目参与者对需求理解的偏差，大家对需求的认识都在统一战线上。

另外由于用户故事的灵活性随着项目的开展是很容易添加或者删去某一些内容的，也就是当开发团队把软件的早期版本展现到用户面前的时候，用户其实会对自己所需要点产品有新的认识并产生新的想法。这种变化在软件项目中非常常见，而且利用传统需求管理模式应对这些变化来说显得有些吃力。

利用用户故事管理需求还有一个特点，那就是下决策的时间。相较于传统需求管理，利用用户故事地图的方法，决策不在项目的初始阶段，而是分散在整个项目过程中离散的状态。传统需求管理文档一旦签订拿到双方的认可后便根据其下决策了。然而故事驱动的方法并不具有契约的性质，最终达成的协议是以结果为导向，以测试结果为准。

简单对比利用用户故事地图来获取需求的方法和传统需求文档管理的区别如表1。

结语

由于用户故事本身并不具有契约性质，使得其在项目中运用起来更为灵活，在针对软件类型的项目中可以很好的应对多变的需求从而对项目计划进行调整。若结合敏捷迭代的管理后更容易在每个迭代间在初始用户故事基础上更多的与客户对话从而细化明确化最终的需求，避免越走越偏最终导致项目失败。

参考文献：

[1] Jeff Patton. 用户故事地图 []. 清华大学出版社，2016.

[2] Mike Cohn. 用户故事与敏捷方法. 清华大学出版社，2010.

[3] Michael G. Luchs. Design Thinking New Product Development Essentials from the PDMA. 电子工业出版社，2018.

[4]Karl Wiegers， Joy Beatty. 软件需求（第3版）. 清华大学出版社，2016.

[5]李俊炜. 软件开发中的需求分析及变更管理研究，无线互联科技，2017（5）.

作者简介：

周盛（1988年1月—），籍贯：江苏如皋，职称：无，性别：女，民族：汉，学历：本科，研究方向：IT项目管理，工作单位：上海药明康德新药开发有限公司。

随便看

科学优质学术资源、百科知识分享平台，免费提供知识科普、生活经验分享、中外学术论文、各类范文、学术文献、教学资料、学术期刊、会议、报纸、杂志、工具书等各类资源检索、在线阅读和软件app下载服务。