【SBE】由需求管理谈起

中午有同事提出一个问题，其实我觉得根本不值得一谈。但很多人有争议，在这里简单记录，并阐述一下自己的观点。

先看故事背景：

某TM   类似于http://192.168.100.100:8080/browse/DAEG-1110 这类已经无效的需求，我们是否有必要不放到任何一个版本里面？因为即使关闭了，它也占了一个数，大家怎么看？

某TM    查看的时候，如果不一个个点开，是不知道是否是无效的，无效的需求也混在有效需求里面，虽然也有一个状态表明是无效的，但是多余啊，--这个不就是坑吗？这个才会增加管理难度的

某PM  统计的时候过滤掉就是了

某TM   如果是无效的，为什么还要专门过滤它呢？新建一个Empty版本，无效的移动到那个版本里。

某TM   有些浪费脑力哈，无效的根本就不应该被展示和被关注，应该淡出到考虑范围之外。而不是要时刻提醒自己有一个个的坑。

某PM  无效的及时关闭，还挖啥坑啊。不要增加管理难度嘛

       ……

       存在矛盾和问题。我们回头看看，其实这里讨论的事情，都涉及到了什么：需求管理、项目管理、项目度量、版本管理…

       我给出的看法是：

首先，无效需求也是需求。只不过是在执行过程中才发现和前期预想的不一致，它和Won't fix或者无法重现的bug类似，都是在项目前行过程当中经历过的一些记录；虽然最终的交付并非有效价值，但也包含了一段思考和分析在其中；

其次，无效需求也应当被统计。它是属于某一个版本下的产物，在项目结束时候，项目总结需要进行统计，和初期的项目计划所提需求对应。

然后，Empty版本没什么阶段属性，即使统计也应当基于一定时间一定版本周期内，脱离这两点单独建立Empty版本统计无效需求是没有实际意义的；

再者，从度量的角度，这些存在也是合理的，即使电信项目严谨一些要求 5个9，那么也存在0.00001的瑕疵在其中。发布标准定的一般是实现80%，而无效需求存在于剩下的20%中。

越是创新型的项目，探索的越多，这种无效需求的可能性就越多。如果没有经过失败的尝试，那么就没有最终的正确结果。

所以个人认为，这个问题没有什么争议的必要。

      

现在大家都在倡导敏捷精益，倡导快速迭代，各种Agile、XP、SCRUM、甚至还有“他爹的TDD开发模式”（Test Driven Development），还有“他妈的TMD开发”( Team Meeting Driven)，完了有些人连ATTD的全称是什么都不知道就开始大谈ATDD的好处，可见我们的Manager们是多么的浮躁，个个以为考了一个PMP就可以了，随便拍拍马屁，这事就成了？而殊不知，正式如此，才导致了项目逐渐的走向死亡。

一个项目的成功，离不开一行一行写代码和DEBUG的“屌丝码农”，和一次次搭环境尝试各种不同场景下的运行状况的“测试童鞋”们。他们才是支撑项目的最初原动力。当然架构师也功不可没，一个“大脑袋”的视野和高屋建瓴版的精妙设计决定这项目的定位。他们才是最可爱的人。他们才是项目的驱动力来源，而绝对不是整天穿梭于各个会议室拿着喇叭催进度的Managers。

我们不需要不懂技术的PM和TM。因为他们一人拿着底下三五个人的薪水，却干着一些拿着没什么真实意义的事情，还美其名曰“度量”，画画Excel，喊喊口号，一天就过了，却不干多少实事。纯粹是对项目成本的一种浪费。还不如用来给底层搞技术的码农们来点加班饮料。呵呵，说的有点过了，就当作开玩笑罢了。

现在BDD和SBE也号称比较火，这个不是什么SB Engineer，而分别是行为驱动开发、需求实例化。我想不论采取什么模式，瀑布还是基础模式，不论玩什么开发方法学新花样，CMMI也是基础。万变不离其宗，如果这二者都没练熟，其他都是瞎扯。

本文转自 念槐聚 博客园博客，原文链接：http://www.cnblogs.com/haochuang/archive/2013/04/12/3017580.html，如需转载请自行联系原作者