分析软件需求说明书利弊（附某人的…

    来到新公司，我挺不习惯的一点是要求写软需文档。之前呆过的公司都不需要写软需。其中还有一家是通过cmm3认证的呢。怎么通过的？临时抱佛脚专人写软需呗。开发不看测试不看。给谁看？评委呗。由此知道国内cmm3认证有多水了吧。既然软需的拥护者和反对者为数都不少。所以我觉得软需是否有用不是个判读黑与白的问题。而是需要权衡弊大于利或者利大于弊的问题。
    软需的利简单说就是有章可循，理想情况下开发按照软需开发，测试按照软需编写测试用例及验证。
    软需的弊则是人力的耗费，不止要考虑编写软需的人力，在开发和测试过程中常发现软需需要修改，维持代码和软需的同步也要花不少心思。而且而且用需也不是一成不变的。当用需改变时，软需也要与之同步。
    什么条件下软需的利可以最大化？我认为需要以下几个条件同时成立：
    1）用需相对稳定。如果没软需，改用需只要改代码和测试用例，有了软需还要改软需，凭空增加额外的工作量。
    2）高质量的软需——这要求软需的编写者不止要熟悉编程，还要熟悉需求，熟悉用户，熟悉交互，不具有反人类倾向。通过评审集思广益反复修改就能达到高质量的软需？我觉得很难。就跟反复代码审核也很难把编程小白的代码改好一样。好的软需编写者不但能符合用需，还能发现用需的不合理或者难以实现之处并提出修改意见。这样的中坚开发者每个项目都应该是有的。否则项目很难成功。但问题是这样的中坚开发人员拉来写软需，成本是很高的。另外当人手不足时可能会两难：要好文档烂软件还是烂文档好软件。
    3）开发人员开发的时候认真看软需。这点似乎很容易也很应该。但是实际编程时这么按部就班的编程人员有几个？当然可以通过制度培养开发者严格参照软需开发的习惯。但这必须建立在有好软需的基础上，否则开发人员一看软需就觉得有问题，肯定会有逆反心理。
    总结：产品经理要强，软需开发者要猛，开发人员要乖。哎。对于我们项目，感觉一点都不满足。不过即使这些都满足，还要考虑下猛将出品的软需的成本吧。
    对于软需，常有一些误解，如没有软需，软件写得很烂，所以说明要有软需。反例：有很多卓越的软件并不是按照软需来实现的，起码绝大多数开源软件压根就没有软需。不要让没有软需成为替罪羊。当然反过来也不能说这么多好软件没有软需，我们软件不好是因为我们有软需的错。我觉得是否有软需不会根本影响软件质量。就跟羽毛球双打第一秘诀——找个赛亚人做拍档一样，提高软件质量的第一秘诀——找群赛亚人来编程，fire那些不合格的。
    软需能弱化吗？我觉得如果有一个专职测试，实时跟踪项目，根据最新用需和实现修改测试用例。那么应该没啥问题。而且从成本角度出发，这么做便宜多了。怎么样，我很有成本意识吧。
    呵呵。说是分析利弊，其实大抵是说软需坏话。因为我觉得软需假定的理想情况很难实现：完美书写软件开发的共同约定，大家严格执行。
    ps：编程有条很重要的原则：don't repeat yourselft，软需和代码是不是违背了这条原则，结果导致总是要联合修改。
    再ps：敏捷的价值观“可以工作的软件胜过面面俱到的文档”中指的文档是用需，软需还是测试用例？我觉得只可能是软需。那如果按软需按步就班编程，还能说是遵守这条价值观吗？

=====================================================
    将此文发给宿醉的牛人后得到答复，我觉得还是很有见地和说服力的。所以将摘要附在下面。
1）互联网产品用需没法稳定。但按敏捷开发每个冲刺中，要完成的故事是冻结的。也就是一个冲刺要做的需求是可以稳定的。那我们如果规定每个冲刺开始前完成sprint backlog对应的软需呢？
2）同意你说的，高质量的开发人员才是王道，牛叉程序员啥文档不要也能搞出好产品。理想状态的敏捷是所有人都以沟通方式来取的对需求的全面理解。但就跟那个 “为啥飢民不吃肉”一样无奈，你也看到，在厦门的实际情况，高质量的程序员可遇不可求。即便是高手比较多的网宿，应该也很难做到每个项目组都是牛人构成 吧。
3）既然实际情况跟那美克星不同，那要如何组织中庸的coder顺利地完成产品开发任务？近南先生曾经说过，“对聪明人要xxx, 但对外面那边蠢人，就要yyyy”。 以沟通的方式完成需求的理解，实际上比写软需，更需要程序员的责任心与主动性。如果软需都写不好，要依赖纯“沟通”方式来干活，就更是痴人说梦了。
4）让中庸的coder写软需，可能质量并不好，但至少能逼着他们在开发前了解到底要做什么东西。而且软需的写作是蛮死板而不需要太多灵性的工作，coder们只要按制度按模板完成就好了。
5）如果只写一个冲刺的软需，量不大，对编写者和评审者应该都不会太痛苦。
6）软需是写“要做什么”。代码是“要怎么做”，这不算repeat吧？ 如果大家要做什么都模糊不清，谈何做好？
7）敏捷执行误区：敏捷是反文档的。文档只是为了达成目标的一种手段，如果这种手段是低效的，那就换一种手段。可是完全抛弃了文档，怎样解决沟通的问题?难道你想每次沟通都完全用手比划，用嘴说，跟不同的人重复表述同样的想法，那样更是低效的。应该清楚文档的本质是把知识显性化。在一个项目中存在很多需要沟通的知识，知识具备两种形态，显性的和隐性的，传统的观念是尽量把隐性知识显性化，即文档化，而忽略了这其中的代价(特别是更新同步文档的代价)。因此，在实施敏捷的时候，需要在团队内明确哪些知识是必须显性的，这些知识可以通过文档交流。哪些知识是可以隐性的，这些知识则完全可以通过口头的方式进行交流，以达到沟通的最佳效率。文档不是目的，有效沟通才是目的。