需求的粒度是项目的心跳

领导常常问，这个需求能不能一个月内完成？研发主管其实也不知道能不能，只能硬着头皮答复“能”。

因为

市场总是紧急的，需求总是实现的越多越好的。

研发总是善良，总认为多做些需求，市场开拓会更顺利一些

研发总是乐观的，总以为需求开发是顺利的，兄弟们紧一紧，加加班，也能够把需求搞定。

可是现实总是不如人意。总有两个黑白老鼠日夜偷走项目的进度。

一个就是现场故障，总会有各种意外的软硬件故障需要研发团队参与解决。

另一个就是需求开发过程中，不断遇到新的问题，技术的问题，人员的问题等。

面对日渐短少的开发时间，研发主管不得不哀叹之余，把项目该做的质量质量保证活动砍了（什么设计评审，什么代码走查，什么单元测试，兼容性、稳定性、性能验证）统统见鬼去吧。

急赶慢赶，总算把一个勉强可以运行的版本交出去了。埋了多少雷，自己也顾不上了。

刚换了一口气，领导也不能让你闲着啊，下一个版本的需求开始了。

技术债务越垒越多，终有一天把研发团队拖入一个人人都想逃离的泥潭。

我把这种现象比做消化不良。就是说嘴巴还在不停的吃，但是肚子已经撑不下了。这似乎是大部分公司的宿命，其背后有着必然的原因。

一个科技类公司大致分为销售、研发和运维等部门。为了挣钱，销售在公司中总是强势的部门。（写到这，想起了下面的笑话）

【技术与销售】技术人员陪销售去打猎，技术开车，把销售送到目的地，销售下车去寻找猎物，然后，不一会拼命跑回来，大喊救命，后面一个凶猛的野兽正追过来，技术赶紧开车门要拉销售逃跑，销售没上车，野兽却钻到车里，销售关上车门，对技术说你把它弄死，我去引一个更大的过来。

从性格上说：销售属于进攻性的，总是千方百计的挤压资源做更多的事情，而与之相对的研发人员相对较诚实保守。如我前面所说的乐观、善良。 在这样的力量对比下，研发总会被驱使着接受自己无法承受的需求。

从需求开发的特点来说，传统的瀑布式开发过程也容易导致研发过多的承接需求。

一个需求从纳入规划到版本实现，大致有这么多的工作要做。

工作量1）基本功能实现

工作量2）性能是否达到要求，涉及性能优化、多线程并发、锁处理，甚至架构都会因此大改动。

工作量3）相应的文档编写（特性指导书、安装配置文档)

工作量4）易用性（比如批量操作，导入导出）

工作量5）安装和升级支持

工作量6）性能统计、监控、告警

工作量7）安全性考虑（密码？数据备份和恢复？）

工作量8）稳定性考虑（看门狗？双机？容灾？）

工作量9）人员培养的考虑，后续定位，分析的工作量，可能出现熟悉这个功能，这个开发工具的人都没有了

工作量10）测试工具开发、测试方法的考虑

可见一个基本功能的实现，只是实际版本开发过程中工作量的十分之一。

在传统的瀑布式或迭代式开发中，一个开发周期大概在6-9个月。在项目立项时，需要规划这6-9个月要实现哪些需求，这时其实是没有底的，往往考虑的基本功能实现的工作量。最终导致规划的需求过度。经常有人问我，这个功能怎么看也就一周的工作量，怎么估算那么多，我好想也回答不了，只是倾向于把别人估计的工作量X3或X4.

在传统的瀑布式或迭代式开发中， 规划的需求过度，在项目的初期看不出来。我在一家大型的电信设备公司从事过多年的研发。我的体会是，需求分析阶段和概要设计阶段主要是系统工程师在自说自话。下游开发和测试人员参与很少（常常由于忙于上一个版本的开发和测试）或者不具备评审的能力，只能学习，还要看领悟能力能学到多少。 而系统工程师脱离编码很久了，对系统架构、大的原理比较理解，但是具体实现已不清晰。

这就造成需求和设计的质量如何不能保证，往往遗漏功能点。埋了很多雷。

但需求阶段和设计阶段往往是按时完成的，因为文档质量评价没有很好的标准。需求过量的问题还不会暴露。

一般问题暴露在集成测试阶段，到系统测试阶段就更恶化了。大量的功能、性能、接口不一致的问题被发现，造成开发测试进度的延误。

如果版本有外部里程碑（xx时间点，必须在xx局点商用）的话，那么就只能带病上岗了，我们通俗的称作“部分发布”或“限制性发布”。

为了赶这个外部里程碑点，整个项目组的心态就被改变了。匆忙和混乱成为常态，项目经理也开始砍需求了，但需求直接又是纠结的，砍了A，可能影响了B。总之是一地鸡毛。

为什么敏捷开发逐渐盛行？我的理解，敏捷开发的特点是把版本的粒度和周期缩小了。原先一个版本可能几十个需求，开发周期6-9个月。

现在一个版本就1-2个需求，开发周期1-2周。这就是PDCA周期非常短。自然能及时调整，过载。如果需求承诺过度了，那么可以立即发现，后面的需求也就不会压过来了。这就是一个项目的心跳，敏捷开发中，项目的心跳是以周为单位的。而瀑布或迭代开发中，项目的心跳是以月或数月为单位的。当发现心跳没有的时候，项目可能已经病入膏肓了。

不管是敏捷开发，还是传统的瀑布开发、迭代开发，要控制好项目的节奏，其本质都是要控制好需求的粒度。只不过传统的项目管理不利于项目经理和系统SE对需求的粒度控制，而敏捷开发中较利于项目经理和系统SE对需求的粒度控制。

为什么这么说呢，举例说明如下所示，（简化描述）

一个需求有三个子流程，经过SE的分析后，三个模块要修改，总共需要实现下面9个函数。假设每个函数的工作量都是一周。

按照传统的开发流程，三个人各自负责一个模块，那么模块1和模块3的工作量都是4周。

整个系统开发周期是四周，开发完成后才能进行测试。

也就是连续四周看不到项目的心跳。

如果按照敏捷开发的方式，那么会在第一个迭代中先实现第一个流程，也就是分别实现函数1、函数5和函数6.

那么第一周就应该有一个子流程发布了。项目的心跳是一周。

项目拥有持续的心跳，就使得项目负载的检测和调整成为可能。