第7章：在项目开始之前
本章讨论了在项目开始之前要面临的问题。
36《需求之坑》
许多人把“搜集需求”当作是项目的早期阶段。
“搜集”一词似乎在暗示：需求已经在那里了，你只需要找到它们就行了。
但事情在很大程度上并非如此——需求很少存于表面上。通常，它们深深埋藏在层层假定、误解、和政治手段的下面。
不要搜集需求——挖掘它们。
如何才能识别出真正的需求？答案既简单又复杂。
简单在于，需求就是对需要完成的某件事的陈述。但复杂在于，它很难被清晰描述。
你应该要找出用户要做特定事情的原因，而不是目前他们做这件事的方式，这很重要。因为你的最终目标是解决他们的商业需求，而不只是满足眼前他们陈述的需求。
有一种能深入了解用户的方式：成为用户，与用户一同工作，像用户一样思考。
你应该建立需求文档。听众的范围是广泛的。
Ivar Jacobson 提出用于捕捉需求的用例概念。
你可以使用UML。
但是不要做任何表示方法的奴隶，只要是与你的听众交流需求的最好的方法，你都可以加以使用。
制作需求文档的一大危险是太过具体，好的需求文档会保持抽象。
需求不是架构，需求不是设计，需求不是用户界面，需求是需要。
你应该看远些。
抽象比细节获得更久。
许多项目的失败归咎于项目范围的增大——需求膨胀。
你会在各种文献中找到许多度量方式，比如：修正的BUG、缺陷密度、内聚、耦合、功能点、代码行数，等等。
遗憾的是，积极追踪需求的项目不是很多。
管理需求增长的关键是——向项目出资人指出每项新特性对项目进度的影响。
你应该创建和维护项目词汇表——定义项目中使用的专用术语和词汇的地方。
你应该把内容都写到文档上，但是将细节用超链接隐藏。
这样既可以在高层巡视，也可以让开发者钻入更深的细节。
37《解开不可能解开的谜题》（确定真正的约束）
你能只用三条直线就把下面的四个点连接起来，并且返回起点吗？不能让笔离开纸面，或是折回已经画过的地方。（Math Puzzles and Games, Michael holt）
解决问题的关键是确定加给你的所有约束，并确定你所拥有的自由度，因为你将在其中找到你的解决方案。这也是有些谜题如此有效的原因，你可能太快就排除了潜在的解决方案。
如果将约束比作是“盒子”。
那么问题并不在于你是在盒子里面思考，还是在盒子外面思考，而在于找到盒子——确定真正的约束。
有时你会发现，自己在处理的问题比你以为的要难得多。感觉上似乎是“走错了路”。
这正是退回一步，问问自己一下问题的时候：
- 有更容易的方法吗？
- 你是在设法解决真正的问题，还是被外围的技术问题转移了注意力？
- 这件事情为什么是一个问题？
- 是什么使它如此难以解决？
- 它必须以这种方式完成吗？
- 它真的必须完成吗？
你需要发现真正的约束，和区分令人误解的约束的智慧。
38《等你准备好》
倾听反复出现的疑虑——等你准备好再开始。
不过很多人都有“启动恐惧症”。
那么，怎样才能知道，什么时候是在拖延，而不是在负责地等待所有工作准备就绪？
一种行之有效地方法是开始构建原型：
- 假如没做多久你就觉得是在浪费时间，那么你最初就是在拖延，请放弃原型，回到真正的开发中。
- 另一种情况是，你得到了启示。
39《规范陷阱》
编写规范是一项重要的职责。
但是很多人发现很难停下来，他们觉得应该将每一处细节都确定下来。
这是一个错误，原因如下：
- 认为必须记录每个细节的想法很幼稚。因为根本无法准确描述出所有东西。
- 语言的表达能力存在着问题。
- 紧身衣效应。没有给编码者留下发挥技巧和艺术才能的权利。
不要把规范和实现割裂，他们是同一事物的不同方面。每一步都应该直接流入下一步，没有人为制造的界限。
不要把规范当作安乐毯，走出来，考虑原型或是曳光弹。
40《圆圈与箭头》（示意图等形式方法）
计算机技术从不缺类似UML等示意图的形式方法。
形式方法有一些严重缺点：
- 示意图对最终用户没有意义，依赖于设计者的解释。因此展示原型更有用。
- 形式方法似乎鼓励专门化，一组人负责构建数据模型，一组人负责考察架构。但不应该有这样的隔阂。
- 形式方法似乎鼓励建立静态关系。但真实情况往往是动态关系。
形式方法能成功吗？
有迹象表明能成功，但是必定经历了一些学习代价。
形式方法只是工具箱中的一种工具。如果在仔细分析之后，你觉得你需要它，那就采用——但要记住谁才是主人。不要做形式方法的奴隶。