《你以为你以为的就是你以为的吗？》是英国哲学科普天王 Julian Baggini 的作品。
借用了一下 Julian Baggini 这个古怪的书名。
用这个副标题真正想要表达的意思是，在需求传达的过程中，我们经常会想当然。需求分析的最大挑战是寻找、沟通和记住（通常是指记录）什么是真正需要的，并能够清楚地讲解给客户和开发团队的成员。在需求传达的环节中，至少涉及了这几类角色：客户，产品经理，开发团队，更为复杂的可能是这样：客户用户，客户，客户产品经理，开发团队产品经理，开发团队，测试团队，运维团队。如此多的环节，如何确保产品需求传达不失真，所有人员理解一致，从而避免出现“你以为你以为的就是你以为的吗”？这里我想借用一下 RUP（Rational Unified Process）里面的一个概念，UP (Unified Process) 提出了一系列的最佳实践，其中之一就是需求管理 (requirement management)。
我没有很深入的学习过 RUP。这里只是基于 Scrum 框架对于系统化的需求管理谈谈自己的一些探索。首先我们来看看需求传递可能出现的问题：
- 客户不清楚自己的需求是什么，传递出来的需求自然也不甚明了
- 产品经理弄不清楚客户倒底要什么，想当然以为客户想要的就是自己设想的
- 开发不清楚产品传达的需求，想当然以为自己理解的就是产品经理的设计和客户的需求
- 测试不了解开发都开发些什么功能，在测试时郁闷无比，提了一大堆客户不明白，产品不理解，开发不想看的 Bug。
- 于是测试会抱怨开发的能力，开发会抱怨产品的需求，产品则会不满于客户的业务逻辑。
所以便出现了我们标题所说的那样，你以为你以为的就真的是你以为的那样吗？？？
归根结底，客户，产品，开发测试没有基于一种统一且系统的方法来发现，记录，组织和跟踪需求，并且大家对于需求的进化关注不够，也就是说在明确需求的过程中，需求是在协作力量的推动下不断进化的，是通过迭代反馈循环不断优化完善的。抛开需求的进化，我们先来思考下有没有好的方法可以统一且系统的管理需求。
我们先来看看 Scrum 组织需求的方式：
- 以用户故事为形式描述需求
- 用户故事要有验收标准
- 用 Product backlog/Sprint backlog 来管理需求
- 以用户故事地图来管理版本规划
显然，Scrum 在开发活动管理和产品交付管理方面提供了非常清晰的实践依据，但在需求管理阶段略我觉得 UP 的需求制品和“实例化需求”中的需求实例更具有指导意义。本文以实例化需求为例。
实例化需求的核心是，让项目的所有干系方进行有效的协作和沟通，用实例的方式说明需求，用自动化测试的方式频繁地验证需求，最后从实例化的需求说明和自动化测试用例中演进出一套“活文档系统”。这套“活文档系统”既可以有效地对系统进行说明，又可以当做交付验收的标准。实例化需求的目标可以用四个字概括 -- 以终为始（Begin with the End in Mind），简而言之：开发启动前，充分澄清需求，明确验收标准，并保证所有相关人员对需求的理解一致。如果无法做到这一点，很可能对团队开发节奏，交付质量及最终结果产生重大影响，甚至导至 Garbage In，Garbage Out。Scrum 中以“用户故事”为单位来传递需求，它即是最小交付单位，又是需求载体。用户故事本身并没有太多需求的详细信息，它只是后续深入沟通需求的一个入口。如何有效沟通？如何确认需求？怎么确认？不仅是传统需求分析的困扰，许多敏捷开发团队也饱受其苦。
“你以为你以为的就是你以为的吗”这种情况在需求沟通中时常发生。实际工作中经常会有这样的场景。
需求交付后，才发现存在场景遗漏。开发人员抱怨需求中没有提到，而产品/业务人员则说这其实是“Commen sense（常识）”很显然，大家都犯了自以为是的错误。为了避免需求沟通过程中的断层，误解，失真，“实例化需求”方法从场景出发，以用户的操作实例来澄清需求。相比一般的需求说明，更加场景化和具体化，其典型三段式结构为：“在什么情况下，做什么操作，会得到什么结果”。
实例化需求的大概步骤如下：
- 澄清价值，与客户沟通协作，以业务目标为起始，通过团队协作找出可以实现目标的范围（Begin with the End in Mind）。
- 举例说明，列出操作并明确操作步骤，这些提炼好的操作实例本身就可以当作交付的验收条件
a. 列举产品要支持的用户操作
b. 明确用户操作的流程步骤
c. 提练出业务规则- 使用UML（统一建模语言）表示法构建领域模型
- 用自动化测试来验证需求，验证的方法有很多，自动部署，持续集成，排除不确定性，对外部系统使用 Mock 等
- 最后从需求说明示例和自动化测试用例中演化出一套“活文档系统”
在协作确定需求范围时需要注意的是：
- 不要把用户自以为的解决方案当做系统需求。问为什么，要解决什么痛点。由团队自己讨论解决方案，划定需求范围。
- 盯紧业务目标，不要把关注焦点转移到怎么做上。
- 在协作的过程中需要大家共同建立需求模型，包括角色，操作，流程，业务规则，以确保大家的认知是一致的，拥有共同的上下文。
- 需求说明描述的是系统和用户之间的交互，不应该描述系统流程。也不应该和代码绑定紧密，陷入技术细节。也不应该过度关注界面。
- 在外部需求不明朗的情况下，可以从系统的工作流入手，梳理需求。在梳理系统工作流的时候，不仅关注系统间的调用关系，也要识别出系统间的数据传递，识别得越明确，对于举例越有帮助。
- 例子应该关注用户和系统之间的交互，而非关注系统本身的处理流程。因此，例子应该包含前置条件、输入、输出。前置条件指的是场景发生时，未作为输入传递到本系统中，但是已经存在，且对业务产生影响的数据。
- 功能模块的例子必须具有精确性（不是简单的是或否的答案，使用具体的例子）、真实性（使用真实数据，从客户那儿获取真实的例子）、完整性（使用不同的数据组合去试验，利用其他方式去检验和测试），并易于理解（不用试验所有组合，寻找隐含的概念）。
- 发现实例太复杂，就把它的复杂度降低，分解成若干个实例。
- 摒弃对业务走向没有影响的实例。如果它们的区别仅在于名称不同，系统对业务的处理完全一样，此时应该只保留其中一个实例作为代表。
- 提炼实例可以由简入繁。可以先把基本的成功情况提炼出来，再逐步推及到各种异常和失败。关注影响业务规则的实例，关注边界条件的实例。
- 实例应当兼顾正反两个方面。
只有团队准备好实现的时候再开始实例化需求，例如迭代开始时。通常建议在 Backlog 梳理时，迭代会议之前输出需求实例。
网友评论