美文网首页
第八章 需求验证最佳实践

第八章 需求验证最佳实践

作者: Seymoure | 来源:发表于2018-02-15 17:55 被阅读53次

需求验证是需求开发的最后一个环节,它也是一个质量控制点,其目标是发现尽可能多的错误,减少因为需求错误而带来的返工。而需求验证最主要的手段就是Review,但是许多需求团队都觉得需求验证比较容易变成形式,收效很少。本章的目的就是帮助大家缓解这个问题。

8.1 需求验证的主要手段

8.1.1 不同正式化程度的评审

8.1.1.1 前三种相对正式的评审方式。

8.1.1.2 后三种相对不正式的评审

》结对编程/结对分析

》同级桌查/轮查

桌查:两位需求人员之间交换文档产物,相互提出意见。

轮查:多位需求人员之间交叉交换文档产物,相互提出意见。

这些活动通常都是私下进行的,企业应该鼓励这种行为。

》临时评审

临时评审通常是个人的工作习惯,最常见最简单的临时评审就是在沟通过程中,由信息接收者进行简要的概括性的回顾,以达成共识。

8.1.2 审查过程概述

对于最正式最规范的审查而言,它有一个完整的过程,包括:规划,总体会议,做准备,审查会议,返工,追踪6个阶段。

8.1.2.1 规划

简单来说,就是规划内容,规划人员。

对于需求相关的评审而言,参加的人员包括:

》需求规格说明书的作者,同级伙伴。

》提供规格说明信息的人员:分析员,客户。

》要根据规格书展开工作的人,开发人员,测试人员等。

》负责相关接口工作的人。

对于需求相关的评审而言,主要的角色有:主持人,作者,评审员,记录员。一般来说,评审员不宜超过6个,否则容易使评审会过于发散。

规划内容,通常不建议一次性对整个需求规格说明进行评审,应该做适当的分解。将在8.2.1 需求验证的5大要点中进一步说明。

8.1.2.2 总体会议

在召开正式评审会议之前,召集参加会议的所有成员开一个简短的会议,讨论,明确要评审的内容,评审的要点,评审所需要的资料,缺陷检查表。

8.1.2.3 准备

评审会效果好不好,关键在于评审者是否提前做了阅读,准备。想让大家在现场提出有价值,完整的建议是很难的。因此,我们应该为评审者提供完整的资料,时间,给大家预先阅读,查找错误。

同时要求所有评审者将阅读时发现的文字,版面错误直接发给作者,不要让这些东西浪费评审会议的时间。

8.1.2.4 审查会议

准备阶段的目标是发现问题,审查会议的目标就是暴露问题,讨论问题,大家对预先找到的问题逐一讨论,得出结论。

8.1.2.5 返工

只有审查没有返工,那么必然将评审变成形式主义,这是对评审活动最具破坏力的因素。建议在每次评审会后,由作者对每个意见汇总,发给所有评审员,并感谢每一位评审员做出的贡献。

8.1.2.6 跟踪

这一步是评审活动中最容易忽略的。

8.2 需求验证的主要误区与解决方案

8.2.1 5大要点

8.2.1.1 思想

Review被翻译成评审,导致存在着评价的意味,实际上Review更多是指复查,是发现问题。

8.2.1.2 方法

在企业中推行即时评审,桌查/轮查等正式化不高的评审手段,是创建企业评审文化的有效手段。

8.2.1.3 语言

在需求评审会中,应该以建议者,协作者的身份与作者对话,而不是评价者。

8.2.1.4 人员

选择合适的参与人员也很重要,要点在于合适,而不是越多越好。

8.2.1.5 内容

》压缩缺陷检查表

对于标准来说,该检查的东西是很多的,但是对于具体的项目,团队而言,不同检查项的意义是不同的。因此缺陷检查表应该进行裁剪,尽量控制在9条以内。

》压缩需求文档

可以通过分多次评审会,可以通过将需求文档按层次或问题与拆分等方式。

8.2.2 需求验证常见的5大问题

8.2.2.1 评审会时,上面开大会,下面开小会

》现象描述,评审会时,常常交头接耳,讨论一些与评审无关的内容。

》解决建议,按照评审关注的内容进行拆分,与其大家一起讨论,不如分主题,分场次,分人员进行周期更短的评审会。

8.2.2.2 评审会成了审判会

》现象描述,在评审会上大家对作者提出过多批评,做出一些负面评价。

》出现原因,作者可能资历较浅,评审者将自己作为评价者的身份,而不是协作者。

》解决建议,评审者需要转换为协作者的角色。

8.2.2.3 评审会成了吵架会

》现象描述,各个干系人之间可能就批评,负面评价等,产生争执。

》出现原因,干系人之间沟通语气教生硬,作者可能资历较浅。

》解决建议,评审者需要转换为协作者的角色,大家要改进语气。

8.2.2.4 评审会成了语法纠错会

》现象描述,在评审会中,很多错误都是这个字写错了,这个词用的不好,这个段落没有缩进,这里有版面错误等。最终暴露的都是琐碎,无价值的细节。

》出现原因,原因有两方面,一是好人主义,评审者心想如果提出一些真的问题,可能作者面子上过不去,所以不谈大问题,只说小问题。二是准备不足,评审者之前没有阅读,轮到他提出建议时,只能现场寻找一些表面上的问题。

》解决建议,好人主义我们通过避免管理者参加,创建企业评审文化两个方面的努力可以缓解。而准备不足,则需要一些策略来解决。可以要求评审者提前提交评审意见文档,如果没有提交则不允许参与评审会议。

8.2.2.5 评审会成了翻书会

》现象描述,在评审会中,提出的问题根本不按页码顺序,一会翻到20页,一会翻到10页。

》出现原因,出现这种现象的原因显然是主持人准备不足,临时让大家的思路随意展开,导致组织不利,影响评审结果。

》解决建议,会议前主持人需要汇总评审意见,按页码顺序进行排列,然后在会议上逐一解决,每过一页还可以停下,让大家现场补充一些意见。

相关文章

  • 第八章 需求验证最佳实践

    需求验证是需求开发的最后一个环节,它也是一个质量控制点,其目标是发现尽可能多的错误,减少因为需求错误而带来的返工。...

  • 软件需求最佳实践

    作为一名测试汪,自己以前更多的关注是测试设计、测试技术方面的内容。对产品人员是如何编写需求文件的过程不是很清楚,所...

  • 增量开发的最佳实践

    本文表面上说了增量开发的最佳实践,其本质是对产品的需求管理的最佳实践,可以指导一个团队进行有效的产品MVP。任何大...

  • 《软件需求最佳实践》——对需求的认识

    迭代和瀑布过程 瀑布风格:基于活动来分解项目,做需求分析、设计、编码、测试,为期一年的项目可能要做两个月的分析阶段...

  • 软件需求分析师入门书籍清单

    1、软件需求 推荐语:需求分析人员的基础知识学习书 2、软件需求最佳实践 推荐语:BA的第二本基础书 3、软件需求...

  • 学习笔记-需求工程最佳实践

    1)成立甲乙双方参与的需求控制组 项目的成功不单是乙方的成功,更是甲方的成功,甲乙双方紧密配合、互相理解、互相合作...

  • Python最佳实践指南

    Python最佳实践指南 Python版本的选择,最好是3. Python解释器,最好用cpython,其他需求可...

  • 开发流程

    需求评审,产出需求文档 设计评审,产出设计文档 代码开发(尽量使用最佳实践,注意要写基本的单元测试) 基本功能开发...

  • [译]Xcode 环境配置最佳实践

    [译]Xcode 环境配置最佳实践 [译]Xcode 环境配置最佳实践

  • 共读《软件需求最佳实践》01

    hello,大家好!我是小婧。今天是国庆假期的第一天,不知道你有怎样美好的计划。我们的共读活动从今天开始啦,希望大...

网友评论

      本文标题:第八章 需求验证最佳实践

      本文链接:https://www.haomeiwen.com/subject/fkkutftx.html