一个系统开发的成败,好的需求是必要条件,这一点毋庸置疑。每一个读到这篇blog的人可以想一想你以前做过的失败项目或者你以前的痛苦经历有多少是需求太磕碜造成的?

经过n年的争斗,大部分人还是不得不承认,文档是需求最好的载体,我们离不了它。请不要说代码是最好的文档,且不说这么多年了敢拍胸脯说代码特别好,特别可读的项目有几个?开发的同学起码不要指望业务人员精通你的编码,其实也不要指望测试人员,也没理由指望,因为术业有专攻。(,跟今天白天的口水仗很贴题啊。)

说到文档,每个人都是一把辛酸泪:

程序员兼职文档人员:老子还要写代码呢,coding没做完还得写破文档!不都在代码里么?

专职文档人员:这些细节怎么可能一开始就想得明明白白啊!老子又不是神,要是了还要你们做毛?客户说不明白,我也不明白,我搞明白了改完文档你都写完了,赖谁啊!?

代码人员:喂喂!这写的都是虾米啊,什么都说不明白,根本看不懂,我就按照我想的来了!什么?说我实现错了?老子昨天晚上coding到晚上一点,你TMD怎么不早说?!

测试人员:需求好烂。。。被测系统也好烂。。。。什么?改需求?什么?开发错了?什么?Deadline到了?WTF!

项目经理:我要死了。。。。。你们这帮废物!

面对失败的项目,大家表面上不说,心里肯定会有上边这些呐喊!

但是没有需求文档又不行,如何能够有同时满足下面所有条件的文档呢?

1.保证所有项目干系人和交付团队的成员都对需求要交付那些东西有一致性的理解。(大家满意)

2.有准确、完整的需求避免由模棱两可和功能缺失造成的无谓返工。(开发,测试,项目经理满意)

3.有用来衡量某项工作是否已经完成的客观标准。(测试满意,项目经理满意)

4.在短时间交付的前提下满足上述要求。(大家满意)

5.文档能够被及时修改,及时使用,易于维护。(大家满意)

6.文档编写成本低,其它变更成本低。(大家满意)

这里面好多貌似都是矛盾的,比如1和6。文档能同时满足准确,易维护,随写随用这3个特性么?《实例化需求》这本书给出了肯定的答案:实例化需求 也就是将需求变为可以执行的验收测试用例,也就是书里说的活文档。如果满足可执行的条件,需求肯定是定义清晰的;跟持续集成联系起来后,代码实现马上可以被验证;如果修改了活文档也就等于同时修改了测试需求与测试用例,代码实现没有及时修改的话,马上就会以测试失败的形式报警,这样一致性可以得到保证。再仔细分析还有好处若干,这简直是一石n鸟皆大欢喜的革命! 有这种好事?

书中给出了N个成功案例,并且是指名道姓的,不信你可以google它们甚至人肉出它们的联系方式去问问。真是一张让饥饿的IT人垂涎欲滴的大饼。真的有这么神奇么?书已经翻完了一遍,里面给出了很多实战的例子,的确相当有启发,但是很多地方也有很多疑问。今后一定要找机会尝试一下,不过在此之前还是先再读两遍,把里边的一些细节吃透再实践。后续会争取把一些书里的关键点和我不懂的地方贴出来。希望有兴趣的同学一起讨论,大牛过来指导一下。昨天跟做咨询的敏捷教练聊起了这个,我问他国内有成功案例么?他说听说过,没有亲眼见过。谁亲眼见过,或者实现过,赶紧出来现身说法造福一下大众啊!谁失败过也晒晒血泪史或者给这种方法论拍拍砖吧!

争取能吃吃这张饼,品品什么味道。