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

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