瀑布与敏捷模式下的 需求和任务

        随着数字化时代的来临，现在大部分行业提供产品和解决方案都是软硬一体的。硬件开发常规使用瀑布模式，软件开发逐渐开始引入敏捷开发模式。所以很多公司都会同时存在瀑布和敏捷两种开发模式。在这两种模式下，需求和任务的定义是有区别的，经常有同学在两种模式切换时，把这些概念弄混淆了，这儿我根据以往实践经验，尝试做一下对比和解读。

一、瀑布模式下的需求和任务

瀑布模式下提到的需求，是一个笼统的概念，通常分为四类：

原始需求：客户原话表达的直接需求。与大家直觉违背的是，客户提的直接需求通常并不是他真实想要的东西。在菊厂有一个经典的需求案例：有一次，有所大学给运营商Y提了一个要求，希望他们在23：00以后关闭大学区域内所有的通话功能，这是客户的原始需求，但这样做能解决客户的问题吗？

业务需求：经过解读后，能描述客户实际业务问题的需求。业务需求分析师或者产品经理通过对客户意图深层次地分析、调研，识别出来客户真实想解决的问题，而用客户能听懂的语言描述出来的需求，我们通常称为业务需求。同样用以上菊厂需求为例：经过反复跟校方确认，他们的真实场景是，学校经常接到学生投诉，有些同学经常在23：00以后打电话，影响了其它人休息。在屡次劝说无效的情况下，校方没有其它好的解决办法，想通过直接关闭23：00-7：00的通话功能来解决问题。因此校方真实业务需求是，解决在校宿舍区域内23：00-7：00 打电话影响其它人休息的问题。这跟他的原始需求其实差别较大，他原始需求是直接给了一个自以为可以解决问题的方案。如果直接按照原始需求来实现，会引入更大的社会问题（120、119等紧急电话怎么办？紧急事件、紧急通话怎么处理？）

产品需求：对业务需求进行产品分析、设计后，通过产品化语言描述的需求以支持特地场景下的业务开展，通常体现为特性、功能等，并不能直接拆解成开发任务；比如手机支持 60W快充；

技术需求：技术层面的需求描述，有多个来源：1）产品需求转化：从系统/技术层面对产品需求、产品设计进行分析，转化成技术实现方案；2）纯技术需求：系统架构师从架构设计/演进的角度提到技术需求；3）技术债：研发团队识别出来的历史积压的技术缺陷，需要在本次项目中解决。

任务：瀑布模式下的任务，是对项目下所有活动的描述，我们通常用WBS来管理，它与需求没有直接、显性的承接关系。除了项目需求外，还可能包括采购、准备开发/测试环境、组织评审、培训等一切项目成功必要的活动。

二、敏捷模式下的需求和任务

敏捷模式下的通常提到的需求，兼有业务需求和产品需求的特点（当然有些也有纯技术需求，我们经常称为enabler），通常按照需求大小进行层级划分：

Epic (专题)：通常是提供一套满足客户多个相关联需求的解决方案，它是最大的需求，通常在1个产品版本周期（3个月）内难以完成的，

Feature （特性）：通常可以满足客户单一需求的服务，可以在1个产品版本周期（3个月）内但难以在1个sprint/Iteration（1~4周）内完成的。

Story （故事）：通常是特性或者功能中相对独立的一部分，可以在1个sprint/Iteration （1~4周）内完成。

Task（任务）：任务通常是直接由Story级的需求（产品&技术需求）拆分而来的开发/测试活动，与需求之间有直接显性的承接关系，通常1~3天内完成。

三、瀑布和敏捷模式下差异对比：

需求差异对比

模式	瀑布	敏捷
区别	通常按照需求来源和阶段区分： 1. 按照原始需求->业务需求->产品需求->技术需求进行分类和顺序演进； 2. 除了技术需求，其它的并不能直接解析成开发任务。 3. 开发团队并不直接看到需求（看方案和任务）	1.全都是业务&产品需求&技术需求，三者之间没有承接和先后顺序； 2.按照需求大小进行分类； 3. 可以直接拆解成开发活动 4. 开发团队全过程中都可以看到feature和story，并可以进行大小估算

 

任务差异对比：

模式	瀑布	敏捷
定义	1. 包含项目下所有的活动，技术和非技术的。	1. 通常只包含由story解析而来的技术活动，例如开发和测试；
与需求的关系	1. 通过对项目范围、方案进行分析和拆解而来，由WBS来承载； 2. 与需求不直接关联;	1. 直接由需求（story）解析而来； 2. 通常结合Kanban方法，用看板来直观承载。
管理者	1. 通常由项目经理跟踪管理	1. 由项目团队一起管理（每日站会）； 2. 通常配备PO和开发团队（部分有Scrum Master），不配备PM