枰绞樾吹奈牡怠�
为什么我们需要正式书写的规范书呢？客户不需要它们。市场和产品规划部门也不需要它们。即便是内容发布者和产品支持人员，他们对规范书的使用也是有限的。因此，谁需要这些荒唐无用的“杰作”呢？为了找到答案，我们不妨把规范书扔掉，看看谁会叫起来。
在那里进退两难
如果我们不再有规范书，开发和测试人员会大叫，“我怎么知道代码应该实现什么功能呀？”告诉他们找项目经理讨论去。然后他们接着抱怨，“项目经理又不会整天在我的办公室里转悠。我需要记录下来的规范书。我必须对它们进行复审、修改和更新。”
是的，这里的确有问题。不是开发和测试人员必须有规范书来复审、修改和更新，而是项目经理没有整天留在附近，一起来讨论用户体验、实现和测试策略。好吧，那如果项目经理这么做了又怎样呢？
如果项目经理跟开发和测试人员整天呆在同一个开放区域里，并且周围摆满了白板，一起为同一个功能集合努力工作，又会怎么样呢？我们还需要正式书写的规范书吗？等等，我听到了更多的尖叫声。
特殊要求
如果没有正式书写的规范书，依赖这些功能的其他团队将会抗议，“如果我们不知道你的代码是怎么工作的，我们怎么知道如何去使用它呀？”这问题问得很好。如果项目经理整天跟功能团队呆在一起，他们也就不可能有时间去应对所有的下游团队，而我们也不可能把所有人都塞到同一间房间里去。然而，下游团队其实不需要规范书——他们需要的是一个小型的软件开发包。不管怎么样，组件团队都得提供软件开发包的，这么做非常有价值。
如果没有正式书写的规范书，“合规警察”（pliance Police）将会咆哮，“的文档在哪里？”这问题问得也不错。合规警察让我们远离伤害。尽管他们的工作不怎么讨好，但却非常重要。他们常常需要正式书写的文档来完成他们的工作。然而，合规警察同样也不需要规范书。他们需要的是完整的合规文档，跟规范书相比，它常常以不同的形式包含不同的信息。
作者注：这些“合规警察”是谁？他们其实是普通的工程师，只不过他们的工作重点是，确保微软的产品在关键领域的正确性，比如安全、隐私、全球可用（没有不合适的委婉语或引用）和顺从所有适用的法律和法规等等。举例来说，他们要求的典型文档包括：威胁模型（安全方面的）、隐私声明、专利权使用条款等。
在上述两种情况下，你都不需要正式书写的规范书。你需要的是其他类型的特定文档，而这种文档会比较容易写，因为它不是可自由发挥的。
txt电子书分享平台
我不记得了
那么我们还需要正式书写的规范书吗？我“不记得”所有的状况了，因此让我们来理一下：
？ 项目经理在团队的房间里度过他们所有的时间，跟功能团队一起讨论用户体验、实现和测试策略。
？ 功能团队为下游团队写一个小型的软件开发包。
？ 功能团队填写必要的合规文档。
我把它们都写下来了，看起来很不错。不过，等一下，这里有个问题。
人们常常健忘。你不得不把想法写下来，尤其当你经常在不同的项目之间切换的时候。很自然，如果一个功能从开始到结束要花费几个月的时间，在这期间可能会有人离开团队，那么信息岂不是都丢失了？！
。 最好的txt下载网
坚持做一件事情
但如果你一次只做一个功能会怎么样呢？那花费的时间就不会那么长，你也不会在项目之间来回切换。团队中有人离开的几率会小一点，而把想法记在脑子里也会容易得多。你只是需要用数码相机把白板上的任何内容拍下来，然后放到一个维基网站上或Word文档中。
这看起来像是规范书，只是没有了让人头脑发麻的长篇大论。它给你留出了更多的时间去思考，以及在白板前合作，而减少了你在座位上摆弄像素和文字的时间。
很好，你把功能团队聚集在了相互靠近的区域，并配备了大量的白板。你一次只做一个功能，直到这个功能做完。你用相机把所做的决定存档。你撰写了对下游团队有价值的专门文档。这听起来像是精益软件开发（你可以在第2章的“精益：比帕斯雀牛肉还好”这篇文章中了解到更多的内容）。妙极了！这就是你停止浪费之后所得到的。
电子书 分享网站
你准备好了吗？
可能极少有团队马上停止写正式的规范书。他们还没有接受“功能小组”（Feature Crew）的概念，即一次只做一个功能，并且从头到尾把这个功能做完。他们不能呆在同一个团队房间里面，主要靠白板来相互沟通。
然而，变化已经开始了。各个部门正在调整位置、相互靠近，因为这样做起事情来更快、更容易。各部门也正在组织功能小组，因为这样做可以更快地得到更高的质量，并且留下较少的未完成的工作。顺着这个趋势，把它们不断整合，那你可以把规范书永远抛弃了。这不是梦想，而是简单时代的回归，并且伴随着经历了多年艰苦奋战才获得的智慧。
。 最好的txt下载网
树立靶子
2007年2月1日：“糟糕的规范书：该指责谁？
规范书基本上都是可怕的。不仅仅是指项目管理规范书，而且也包括开发规范书和测试规范书。我说的“可怕”，主要是指难以撰写，难以使用，而且难以维护。你要知道，这很可怕！规范书往往还是不完善的，组织得很差，并且没有得到充分的复审。规范书永远都是这个样子，也看不到有任何变好的迹象。
为此，我想要指责项目经理，部分原因是因为我喜欢这么做，但更主要的还是因为他们是糟糕规范书的始作俑者。然而，事实不允许我指责项目经理。人人都在写糟糕的规范书，而不只是项目经理。即使项目经理偶尔写出了上好的规范书，但其他大部分的还是很糟糕的。不管谁来写，上好的规范书总是难以撰写和维护的。
如果项目经理不该为那些以次充好的规范书承担罪责，那么该指责谁呢？管理层将是最直接的目标（另一群我喜欢指责的人）。事实上也是，有些组织，比如Office部门，一贯以来写的规范书都比其他部门的要好。因此，管理层显然在其中发挥着作用。然而，Office部门这么多年来调换过很多次管理层，因此，这里的原因必定比主管的人更加深层次。
现在清楚了，我应该去指责规范书过程——我们是怎么写规范书的，以及我们使用什么工具。这个过程是繁琐、艰难并且乏味的。规范书模板冗长、吓人，复杂到无法驾驭。所有这一切使得要写成一份上好的规范书，比披着皮大衣、穿着拖鞋想要去赢得一场马拉松比赛还要无望。
一些落后于时代的杞忧者可能会说：“规范书过程如此荒谬紊乱是有原因的。所有的模板元素和过程步骤都是用来避免以前发生过的灾难的。”看到了吧，你不必去担心从公司高层下来太多的官僚主义，其实，在下面的基层已经自己累积了很多。
病态的过程总是源自于最好的意图。麻烦的是，这一路走来，最初的目标和意图都不知不觉地迷失了。唤醒这个目标和意图，使用新的、更好的方法去实现将会使它们自动现身。
作者注：我在波音公司工作了5年。在那里，不是所有、但绝大部分官僚主义看起来都来自于公司高层。我已经在微软工作了12年。在这里，不是所有、但绝大部分官僚主义看起来都来自于基层。我们在最底下的层次，工作独立，很自由。有时候这也意味着，我们被授予了足够的绳子用于勒死我们自己。
沟通分解
所有项目管理、开发和测试规范书的目标，都是为了跟不同时间、不同地点的人进行设计和设计决定的沟通。我们想要使这种沟通变得容易而稳健，并且进行大量的反馈和质量检查。
假设你还没注意到，这里有4个独立的要求：
？ 容易
？ 稳健
？ 反馈
？ 质量检查
每个要求都可以通过一个不同的解决方案来满足。“我们只需在规范书中多加几节来覆盖所有的要求”，这种方法跟“我们只需给这个类多加几个函数来实现所有的功能要求”一样的愚蠢。我们还是对这些要求逐个来分析吧。
txt小说上传分享
保持简单容易
规范书必须要容易写，容易懂，并且容易维护。它应该使用标准的符号（比如UML）来绘制图表，使用通用的术语用于文字表达。它不应该承载太多的内容或者说得过于深入。
格式越简单越好。在“工程卓越手册”（Engineering Excellence Handbook）中的通用规范书模板有30节之多，并且还有3个附录。而上好的Office规范书模板也有20节。它们都太复杂了！
一份规范书只需要3节，再加上一些元数据：
？ 需求：为什么会有这个功能？（跟应用范例和客户角色联系起来。）
？ 设计：它怎么工作？（图片、动画和图表特别有用。）
？ 问题：做了什么决定？风险和权衡都有哪些？（比如依赖关系。）
？ 元数据：标题、简短描述、作者、功能团队、优先级、成本和状态。
就这些了！“状态”元数据可以是个工作流，也可以是个检查清单，但不能太复杂。
“但威胁模型放在哪里？还有隐私声明呢？源代码插桩或者性能度量呢？”我可以听到你在提出这些要求。请你冷静一下！这些条目属于质量检查，我在后面很快就会谈到。规范书结构本身是简单的，比实际需要的多一点或少一点都不行。这样才能容易写，也容易被人读懂。
在线资料：规范书模板（Spec ）。
变得稳健
规范书必须是稳健的。它必须是可被验证的，并且所有定义的功能需求和质量需求都能被满足。你可能会问，“怎么做到？！”但你说“怎么做到？！”究竟是什么意思？怎样在第一时间验证需求？那就要编写测试，对吗？对！这就是你怎么写出一份稳健的规范书的方法。在规范书的第一节中，当你列出功能和质量上的需求时，应该包含如下内容：
惟一标识 优先级 功能或质量 简短描述 相关应用范例 用于验证需求的测试
如果你不能指明一个测试来验证一个需求，那么这个需求就不能被满足，因此要把需求丢弃。不能丢弃？那好吧，重写需求，直到它能被测试为止。
作者注：我相信，一个可靠的设计把“测试”和“需求”放在基本同等重要的地位。每个需求都应该有一个测试。每个测试都应该基于一个需求。这将导致：清晰而可被验证的需求；更加全面的测试；一致的完成标准（即所有测试通过等于所有需求得到了满足）；以及更好的设计，因为测试驱动的设计自然要更加简单，更加内聚，具有更松的耦合。
书包 网 。 想看书来
获取反馈
在规范书付诸实现之前，越多的眼睛看到它，它就会变得越好，并且将来要求的返工也会越少。如果你想很容易就能获得反馈，你也想别人很容易就能提出反馈，至少你要将规范书草稿放到SharePoint上，并进行变更跟踪和版本控制。做得更好一点，你可以把规范书放到一个维基站点上去，或者贴在功能团队主要活动区域的一块白板上。
撰写规范书的这个过程、反馈和变更管理需要有多正式呢？像我在前一个栏目讨论的那样（即本章的“停止写规范书”那个栏目），正式的程度取决于沟通是否直接，以及沟通的“带宽”有多大。在同一个共享区域、同一个时间、工作在同一个功能的人们，他们可以使用很不正式的规范书和过程；而在不同时区、不同时间、工作在不同功能的人们，他们则必须要有高度正式的规范书和过程。
不管怎么样，你想让规范书随时都可以修改，直到团队认为它不需要再改为止。那你怎么知道规范书不需要再改了呢？答案是，要等到测试团队验证规范书通过了所有的质量检查。
集成质量检查
这是我们目前正在使用的规范书最离谱的地方。各个部门不是把安全、隐私和许多其他问题当作质量检查，而是把它们一节一节单独地写在了规范书中。这是个灾难，原因是：
？ 规范书变得更大并且复杂得多。
？ 作者必须在各节中复制信息。
？ 读者对后面的节次重视不够，导致严重的质量缺口。
？ 设计变得难以理解，因为它们的