为提高研发和测试质量而规范Scrum项目需求描述

最新推荐文章于 2022-06-12 14:46:23 发布

糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖

最新推荐文章于 2022-06-12 14:46:23 发布

阅读量164

点赞数

本文链接：https://blog.csdn.net/cpongo4/article/details/89112682

版权

\
关键点
\\
不规范的需求描述会对项目产生不利影响。\\t
某项目需求描述标准化前后的状态比较。\\t
需求描述统一的八大好处。\\t
标准化对测试过程的积极影响。\

业务分析人员之间会经常讨论需求的描述格式。在这篇文章中，我将分享我在这方面的经验。我最近有一个项目。在这个项目中，所有需求描述采用了某种标准化格式。这不仅改善了测试人员和开发人员的体验，提高了团队的生产力，而且建立了更有效的项目流程。

没有标准的需求描述隐患

新员工。当产品经理管理需求的时候，他们经常没有分配足够的时间来合理地描述这些需求。这主要是因为时间紧迫而马上需要开始研发的压力又十分巨大，亦或是产品经理缺少能以恰当方式整理需求的必要技能。无论如何，研发能否顺利开展都取决于研发团队的经验和相关应用经验。但是，当新专家参与项目时，会发生什么事情？合适的文档可以无缝地向新团队成员介绍这个项目和正在研发的产品以及服务。这对于大型长期项目尤为重要。因为缺少这样文件会到导致项目运行过程中遭遇更多严峻的挑战。

估算。如果需求是以一种随意的方式进行描述，没有互相理解的规则和明确的标准，当出现无法回答的问题时，需求就无法被估算。万一有遗漏，而开发人员已经开始研发，那么就会出现瓶颈时期，浪费时间而且延误开发。

时间安排。没有规范的需求描述，我们将难以创建可以持续执行的可靠的项目计划。当产品经理跳过详细的需求文档工作，开发的质量会由于更多的漏洞和需要时间去修复它们而大打折扣，使得功能的实现需要比预计更长的迭代时间。

Scrum项目规范需求描述前后

规范需求描述对研发的直接影响可以从下面这个例子看出来。某大型的社交媒体公司拥有好几个数以百万计客户的热门网站。这是一个快速发展的敏捷项目，股东设定下很高的市场目标，现有的文档被压缩到只为用户和开发目标提供服务。股东对数百页文档的创建和维护压根不感兴趣，而这恰恰是大多数敏捷项目有用而且常见的做法。

客户已经有了他们自己的开发团队和许多雄心勃勃的计划，但需要更多的资源来实现它们。因此，他们需要额外新的研究人员、分析师和开发人员的团队支持，将来还有增加QA（质量保证）专家的计划。

当新的团队聚集在一起时，产品经理的时间安排使他们能更专注于业务的发展方向、战略和与企业主进行谈判，而新项目领导能够开始为研发和确保质量准备彻底的、结构化的、完整的需求描述。

全球范围内分布的团队：一部分研发团队在美国不同的州，另一部分是在明斯克。企业所有者和产品经理居住在美国，而用户则散居美国各个时区。由于所有团队成员间频繁和有效的沟通是项目重要的一环，时间差异让沟通变得更复杂。

在标准化需求描述之前

在实施标准化需求描述之前，用例的描述没有任何特定的格式：需求不够详细；案例缺失或案例太短；总体来说，缺少足够的开发人员。这导致了一些负面的后果，包括：

估算困难。在培训会议期间，问题出现了，在问题得到回应之前，都没有估算充足时间的办法。

问题和差距。在开发和测试阶段，您可能会发现一些重要的方面没有考虑实现功能（例如，遗忘了某些场景、异常流程等）。

浪费时间和精力。在这一点上，整个团队的有效性会受到影响：没能完成预计的任务，因为它们没有包含实施额外的需求；任务可能无法在迭代结束前完成；由于延迟推出新功能，用户不满意。此外，还需花费更多的时间向相关领导解释为什么需求缺失和为什么开发团队需要重复实施功能和测试任务。

标准化的需求描述后

为了改善这种情况，研发团队开始使用“经典”需求表达语句的标准描述方法：

\
“作为一个\u0026lt;用户角色/类型\u0026gt;我要\u0026lt;一些功能\u0026gt;，以便\u0026lt;从这个功能中受益\u0026gt;”
\

此外，以下模板的基础上，使用接受案例，：

\接受案例1：\------\\假设（某些上下文/前提条件）\和（一些更多的上下文/前提条件）\当（由用户执行的事件/行动）\然后（预期的结果-根据上述用户用例，什么应该发生以满足用户的需求）\\接受案例2：…\-------\

项目一开始，团队新开发人员都要从学习新的系统开始，他们不会只获得一个简短帮助说明，比如“当审批在队列中的影响因素时，系统应在仪表板发出警告。”

引入上述格式的结果就是开发人员和质量保证工程师获益于详细的步骤和相关页面的链接的完整描述。这显著减少了问题的数量，并且关于“质量”和相关指标的要求都由于记录详细而变得清晰。

当然，在需要的情况下，我们可以在提供用户的描述和接受案例的同时，提供支持性的东西。这些包括UI模型来说明在UI的变化、设计规范中变化影响最终用户接口和多个图表等。在大多数情况下，图表都是用来说明过程中的变化的，并向整个团队展示由于执行一系列用户描述，系统模块需要做什么全局性改变。

有主要接受案例的用户描述项目案例：

作为一个客户服务经理，我想能够从搜索结果中排除已经被调查的人员，以便我容易区分用户是否已经加入调查，并迅速将新登记的用户加入每日调查。

\接受案例*：客户服务经理将某些人排除在被调查成员之外\\假设客户服务部经理进行调查，他/她希望邀请新用户\并有用户已经被邀请到本次调查\有新的用户还没有被邀请\当客户服务经理勾选“排除已参与调查成员”框，并应用过滤器\然后显示的用户列表不应该包括已被选中的要过滤的用户。\

*上述案例成为三个现有案例中选出的最重要的一个案例，以便创建用户描述以确保全面覆盖。

统一需求描述的好处

360度无死角。当基于一个标准的模板进行完整的描述时，问题会显而易见而不容易被忽略。模板指南推动产品经理和团队认真思考流程中的每一步，并提出更多的问题。这些问题澄清后，用户描述才会被估算和研发。因为后期和项目关键期遇到的问题减少了，因此节省了团队的时间。因此，所有的过程都变得更透明并且项目预算能更有效地实施。\\t
全覆盖。可能性很大的是，所有可能和需求相关的分支和替代方案将被全面描述并附上相关细节，以提高研发质量和简化测试。\\t
更好的性能。作为前两个好处的结果，整个团队的表现会更好，因为用户或测试人员报告的用户描述执行的错误少了。性能也更好了，因为不需要浪费时间进行解释，更多的任务能按时完成，用户用例不会无法实现。\\t
每一个需求、过程或功能都归档整理。当运作一个大的项目时，要同时开发不同的模块，涉及复杂的功能和成千上万的用户与多个用户角色，多方面沟通，使业务分析师不可能记住每一个项目细节。有了标准化需求，他们可以简单地搜索每一个问题的答案，包括作为一个单独的案例或案例步骤的用户描述。\\t
更好的终端产品。为每个功能在JIRA加入统一描述后，不仅可以帮助项目新人，而且内部运作的全面描述和理解也有助于全体成员对系统本身的整体理解。\\t
节省沟通时间。特别是当涉及到外包项目时，往往还有时间差异，每个人都会得益于它能使研发没有障碍和瓶颈。\\t
更高的开发质量。总体研发质量更高，因为每个人都以同样的方式无歧义地理解需求。因为估算更简单，进度规划也更容易。\\t
更容易修改需求或场景。如果花足够的时间写详细的需求，那么，修改它们更是毫不费力。业务分析师澄清和描述需求的投入将会在整体上节省时间和金钱。\

标准化与测试

需求标准化可以让测试人员更容易了解系统、系统功能和模块。测试变得更顺畅，因为接受的案例覆盖所有的功能性流程的细节。因此，他们的时间可以更多花费在测试上，而不是学习了解这个系统。如果有功能某方面遗漏，测试人员也可以提醒开发者及产品经理，进一步完成需求描述完整。

此外，详细的描述缩小了功能或模块上的信息，因此测试人员明白，如果某东西设想要运作得和需求描述一样，那么它必须不差分毫地实现。必须减少基于个人的意见或观点的误解和曲解的情况发生。

管理不断变化的需求

对于没有文档的项目，在JIRA中保留用户描述，对未来项目业务分析师、开发团队和加入项目的其他人都是安全保障。如果需要改变系统过程的任意部分，这很容易。这是因为在JIRA中有全面的关键字搜索功能，你可以在特定的案例中发现需求并且看看需要考虑哪些案例。

同时，在这个特殊的项目，当对最重要的功能实施额外测试的时候，可靠的和感兴趣的用户将被指派为JIRA相应任务的“观察员”。他们将进行验收测试，以了解该功能是否可理解，以及在发布之前它被完全正确地实施。他们将从一开始就盯着这一任务，所以他们可以跟踪需求发生了什么变化，一旦创建需求，他们检查它的描述，并让业务分析师和产品经理知道是否需要更新。从接受案例的角度描述需求，这有利于他们明确自己到底需要什么，并确保描述不会模棱两可。

结论

合理地统一需求描述格式与项目的成功密切相关。迭代过程变得更容易，更少出现错误和延迟，每一步都给整个系统增加了价值。团队获益于更简单的时间安排，从而获得更快的发展，这对可能缺乏资源的大型项目更为关键。

就我们的项目而言，企业的股东受益于良好的预算，这些预算不是浪费在修补漏洞上，而是致力于实现预期的新功能。标准化需求描述的实施使整个项目运行更为顺利，使团队能够快速地提供新的功能模块和功能，同时也满足了所有的期望，最终用户高兴，股东满意。

作者简介

Elena Belkovskaya毕业于白俄罗斯州立大学，获经济学学位。在加入Itransition之前，她是一名经济学家。在Itransition，她是业务分析师。她使用瀑布模型和敏捷方法将七年的经验用于信息技术。在她的工作中，Elena有效地将其良好的分析能力运用于在企业项目生命周期的所有阶段，包括需求开发和管理、功能和培训文档、业务分析规划和估算、项目需求现场和远程通信以及系统的设计问题等。她热衷于通过培训课程和参与领先的行业会议来提高她的技能。