接到需求任务，要先做哪件事？

川长思鸟来 2023-09-23 17:08 65阅读 0赞

注：笔记摘自《10x 程序员工作法》

## 需求描述的问题 ##

在软件开发中，需求是软件开发的一个重要组成部分，但不同的需求描述方式，可能会影响我们程序员对需求的理解。  
因为信息的传递是会衰减的，不可能把理解的信息 100% 传递给另外一个人，而这中间，如何传递（也就是如何描述），将直接决定衰减的比例。  
很多公司的软件开发模式是基于**功能列表**的，通常这种功能列表只是一些简单的描述，并不能看到全局！  
很多团队的一个状态就是：程序员们都知道要开发的功能是什么，但这个功能是谁在什么样的场景下使用的，很多人却回答不上来。  
**这种功能列表式的需求描述方式，将一个完整的需求敲成了碎片**。 只有所有功能全部开发完成，对接在一起的时候，才是“破镜重圆”的时刻。  
大多数人并没有一个完整的图景，这就相当于看不到完整的“终”。顺着这个思路做下去，会在最后关头遇到许多意料之外的问题，其结果必然是手忙脚乱。

## 了解用户故事 ##

一种新的需求描述方式：用户故事（User Story）。它是站在用户的角度来描述了一个用户希望得到的功能，关注用户在系统中完成一个动作需要经过怎样的路径。既然它是“故事”，它就需要是一个完整的场景，可以讲述出来。

## 用户故事 有什么用？ ##

以用户密码登录为例，看看用户故事长什么样？  
一个完整的用户故事大致包含以下几个部分：

*  标题，简要地说明这个用户故事的主要内容，比如：注册用户使用用户名密码登录。
 *  概述，简要地介绍这个用户故事的主要内容，一般会用这样的格式：  
    As a （Role）：作为一个什么角色  
    I want to （Activity）：要做什么样的事  
    so that （Business Value）：以便达成一种怎样的效果  
    其中最重要的是，告诉别人为什么要做这件事，虽然只有一句话，却往往是很多人欠缺的思考，只知做，不知为何做。  
    举个概述的例子：作为一个注册用户，我想要通过用户密码登录，以便我可以使用注册用户才能够使用的服务。
 *  详述，详细地描述用户故事的完整流程，可把操作流程、用户界面等信息都放到这里。  
    主体详述比如：用户使用正确用户名和密码登录，就可以登录成功；如果密码不正确，则登录页面提示用户“用户名密码不正确”。基本上，看到这个部分，开发就可以在心中描绘出这个用户故事的样子了。
 *  验收标准，描述一个正常使用的流程是怎样的，以及各种异常流程系统是如何给出响应的，这是开发常常会欠缺的思考。它会把详述中很多叙述的部分变成一个具体的测试用例。比如，下面的两个验收用例：  
    正常场景：给定一个注册用户张三，其用户名是 zhangsan，密码是 foobar，当张三使用 zhangsan 和 foobar 登录系统时，可以成功登录，登录成功后，跳转到用户中心。  
    异常场景：给定一个注册用户张三，其用户名是 zhangsan，密码是 foobar，当张三使用 zhangsan 和 wrong 登录系统时，登录失败，在登录页面上提示“用户名密码不正确”。

**团队协作中，之所以会对需求是否完成产生分歧，是因为大家对于需求完成的定义不同。** 解决这个问题非常关键的一点就是**验收标准**。用户故事的关键点也是：验收标准，它可以清晰地定义出需求边界。  
**验收标准非常重要的一环是异常流程的描述**。而异常流程则是最容易忽略的，也是产生扯皮的关键环节。应该一开始把它定义清楚。怎么才算做完需求呢？验收标准说了算。  
采用用户故事整理需求，可以提前发现逻辑是否有漏洞。在写完了主要流程之后，再去看一下验收标准，为自己的开发查缺补漏。因为是标准，达不成就不算任务完成。  
当开发对照着验收标准自测完，证明系统确实能够跑通。这之后，测试人员接手过去，做更系统的测试。已保证交付质量的提升。  
\*\*验收标准给出了这个需求最基本的测试用例，它保证了开发人员完成需求最基本的质量。\*\*如果了解 BDD（Behavior-Driven Development，也就是“行为驱动开发”），就可以按照验收标准中给出的内容编写验收测试用例了。  
在实际工作中，许多产品经理把需求交给开发人员之前，很多细节是没想清楚的，那种功能列表式的需求常常只包含了正常路径，那些缺失的细节就是在后续的过程中，由开发人员补全的。用户故事就是一种固定的格式，方便把问题想清楚。  
**如果团队采用用户故事的格式进行需求描述固然好，如果不能，在功能列表中，补充验收标准也会极大程度地改善双方协作的效率。**

## 项目中的角色 ##

在开发一个功能特性的时候，因为一些环节的缺失，我们不得已扮演了很多的角色，其中之一就是产品经理。你是一个专业的程序员，但大多数情况下，你却只是一个业余的产品经理，“丢三落四”就在所难免了。  
虽然名义上是程序员，但当**拿到一个需求的时候，要做的事不是立即动手写代码，而是扮演产品经理的角色，分析需求，圈定任务范围**。事前分析绝对比你拿一个写好的系统给老板，而他却告诉你这不是他想要的，好太多了！  
扮演不同角色的时候，我们的思考模式是不同的。还是以开发用户名密码登录为例：  
如果只扮演开发人员的角色，想到的可能是：输入正确的用户名和密码可以正常登录，输入错误的用户名和密码不能登录，并且给出提示。  
但如果扮演的是产品经理的角色，会从产品的角度进行思考，也就会看到不同的内容，比如：

*  登录是否需要验证码
 *  是否需要第三方登录
 *  是否记录登录日志
 *  …

以上可能并不是我们都需要完成的功能，但站在分析的角度，这都是我们要考虑的问题，一个登录功能，绝不仅仅是用户名和密码校验那么简单的。我们能想到这些，仅仅是因为我们正在扮演一个不同的角色。  
所以，**如果你要兼顾开发人员和产品经理两个角色，建议你先扮演好产品经理的角色**，多花点时间把验收标准制定好，再回到开发人员的角色上去写代码。毕竟，**最好维护的代码是没有写出来的代码。**

## 总结时刻——在做任何需求或任务之前，先定好验收标准 ##

需求，是软件开发中的一个关键环节，一旦需求理解出现问题，势必会造成大量的浪费。传统的功能列表只是简单罗列了要实现的功能，丢失了大量的上下文，会导致团队成员对于需求“只见树木不见森林”。  
在大项目中，更是会将一个功能分拆到多个团队中，每个人看到的只是功能碎片。于是，后来产生了其他的需求描述方式，比如用例和用户故事。  
在实际的开发过程中，大量的分歧来自于对“需求完成”的定义。当我们把“以终为始”的原则应用在需求领域中，就会注意到，用户故事有一个非常重要的组成部分是验收标准。  
验收标准不仅仅描述出了正常流程，也会关注到异常流程的处理，它也是我们验收测试用例的起点。一旦事先定义好验收标准，大量的扯皮工作就随之烟消云散了。  
理解了验收标准的作用，即便我们不使用用户故事来定义需求，依然可以在功能列表的每个功能定义中，增加验收标准。