详细设计的瓶颈
详细设计的重要性，个人认为是毋庸置疑的。需求说明书从用户的角度描述了软件系统应有的模样（如功能、性能、用户界面与交互方式等方面的要求），而详细设计则把用户需求映射到计算机这个层面，即软件系统应该如何运作才能展现出用户期望的模样？
撰写详细设计是一个逐步细化、深入的过程。设计撰写人必须与系统分析员反复讨论，以透彻理解用户需求；一项需求可能有多种方式实现，设计者必须与系统分析员确定该需求将采用何种方式实现，将达到何种效果，以消除将需求映射为设计的歧义；讨论过程中还可能会发现需求有不完备甚至错误的地方，在需求重新确定后设计者需修正设计。设计文档必须写清楚各个模块/接口/公共对象的定义，列明程序的各种执行条件与期望的运行效果，还要正确处理各种可能的异常。此外设计文档应该遵循一定的写作模式与版面风格，使用统一的术语或惯用语，使得小组成员很容易理解。以上这些活动综合起来将是一个很细致、很耗时的工作过程。
就个人所知，一些公司的详细设计通常是由程序主管或少数核心的程序员撰写的，他们通常也是系统架构的主要作者或维护者。因为他们在开发团队中技术最为精湛，对架构最为熟悉，他们最有资格评价现有架构是否能适应新的用户需求，采用何种方式实现需求对架构的冲击最小。
但是由少数人来负责所有的详细设计可能造成开发过程中的瓶颈。当任务比较集中的时候，设计者可能忙得透不过气，而负责实现的同事反而在等米下锅，比较清闲。于是为了让自己不成为拖累进度的“罪人”，某些设计者就会采用一种快捷方式来交付设计：他们会与系统分析员进行初步的讨论，然后撰写一份粗糙的但仍然叫做详细设计的文档，把它交付给负责实现的同事，再通过讨论、即时通工具、电子邮件等方式解答对方提出的疑问。但由于详细设计本身不完备，他们不得不花费更多的时间和精力与负责实现的同事沟通；而且他们却很可能忘了把这些交流的成果更新到详细设计中去！（或许是他们太忙，没有足够的时间，又或许是他们认为既然产品已经实现，那么详细设计也就不必维护了。）其结果很可能是当产品开发出来后，我们才发现它跟用户要求的完全两样！原本在详细设计阶段就应该发现的需求漏洞与在那时应该确定的技术方案在实现阶段甚至测试阶段才暴露出来，而这时大家往往有木已成舟的感觉，改动的难度比设计阶段高数倍甚至十倍以上。
全员设计
为什么只有少数人有撰写详细设计的特权呢？或者为什么只信任那少数人的能力呢？难道小组中的其它同事就不可以参与设计吗？
全员设计的含义就是把详细设计的工作进行适当地分解，把它们分摊到小组内其它同事身上，让大家都参与设计。这可以说明如下：
当一组用户需求基本确定下来后，程序主管需要估计需求的相关性、需求的优先级、设计的难易程度、设计的工作量等，将该组需求分解为一或多项设计任务，并指定给适当的同事。参与设计的每个人必须负责至少一项设计的撰写任务。
设计者从系统分析员处获得详细的用户需求，并与系统分析员反复沟通以透彻理解用户需求。他还要分析系统架构及产品的已实现与/或已规划部分，理解架构的设计理念，理解产品不同模块之间的协作关系，理解架构与产品之间的约束和依赖。当然对系统架构和产品的分析不可能穷尽每一个细节，只要分析与即将开发的模块相关的内容即可。在我看来，这些内容包括：
a)在业务或操作流程上相关的模块
b)在业务上存在数据或控制耦合的模块
c)在技术上可能引用或依赖的模块
分析了这些内容之后，设计者就可以撰写详细设计了。当然也可以一边分析，一边撰写和整理。
一项设计任务，它可能需要多个程序员完成。比如用户界面或网页由某位或某组同事负责，而业务逻辑组件则由另一位或另一组负责，数据库部分则又由其它同事负责。设计者必须考虑他们的立场，以各方面都相对容易理解的方式写清楚主要的模块/接口/对象定义，明确相应的调用规则与主要逻辑处理。
如果某项设计任务所涉及的内容太专业化，设计者并不熟悉相关的内容（比如某位C#程序员并不熟悉如何编写一个存储过程），他可以用描述性的文字说明该部分的设计要求，并知会相关的同事补充。其它同事在补充时可以对这些描述性的文字重新整理，以更加确切地表达设计内容，更符合文档的书写惯例。
在设计文档完成后，设计者必须把他提交给程序主管或由程序主管指定的程序员审阅。审阅的目的有二：
a)检查该份设计是否有错误或漏洞
b)检查该份设计是否与其它设计冲突
个人推荐由其它程序员而不仅仅是程序主管来审阅。这有两个好处：
a)程序主管的审阅工作不会再次成为瓶颈
b)更多的人来审阅，有可能发现设计中更多的缺陷
不用担心等待多个人的审阅意见是否可能导致一份设计滞留很久。大家可以并行地工作，不必是A审阅后才能B审阅。可以交叉审阅，即A的设计由B、C审阅，B的设计由A、C审阅等。审阅意见可以用多种方式（如讨论、即时通工具、电子邮件）反馈给设计者，设计者负责汇总这些意见并修正设计。以个人的经验而言，通常设计交付审阅后半天内就可以收到反馈意见了。
设计经过反复地修正直至没有人再提出修正意见，这时就可以由程序员实现了。以个人的经验而言，一份设计通常两、三轮反馈后就可以定稿了。如果多次反馈后仍不能定稿，极有可能是：
a)需求尚未明确，各个方面（包括客户、系统分析员或设计者）对需求的看法不统一
b)技术或系统架构存在严重的限制，无法用较方便的方式实现
好处、风险与不适用的团队
全员设计可以带来以下明显的好处：
1.有助于平衡工作量，加快开发进度。详细设计的任务分解后，程序主管或核心程序员可以有更多的时间处理其它的事务，比如关注软件的开发质量或改善系统架构。详细设计的撰写任务分解后它们可以并行地撰写，这将极大地提高设计撰写的进度，节约时间。
2.有助于培养程序员的大局观。每位撰写设计的程序员不再仅仅只关心自己负责实现的模块，他必须从更高的层次考虑和理解设计。
3.有助于加强同事之间的交流与协作。设计者需要与系统分析员、其它程序员、审阅者进行反复的交流和沟通，实际上每份设计都是多人协作的成果。更多的沟通有助于集思广益，有助于避免一、两个人的倾向性意见导致错误的设计。每位设计者都需要对自己撰写的设计负责，他还要向其它同事的设计提供审阅意见或技术建议，彼此的工作是互相支持和依赖的，这有助于减少“只扫自家门前雪，不管他人瓦上霜”的想法。
推行全员设计的潜在风险：
1.在某种意义上，全员设计可能增加交流的成本。两个人之间有一条交流途径，三个人之间最多有三条，四个人之间最多有六条。途径越多，信息量就越大，而这些信息不见得都是有用的信息。详细设计的任务分解后，不可避免地有更多的人参与交流和沟通，大家要花更多的时间来理解他人的想法，也可能要花更多的时间向他人阐述自己的观点。特别是在并行撰写详细设计的过程中，系统分析员反而可能成为另一个瓶颈了。但从总体上来看，在设计阶段花费适当的代价发现更多的问题，比在实现阶段或测试阶段再发现问题，仍然是划算的。
2.分解后的详细设计可能引入冲突的设计内容。由于设计由不同的程序员撰写，他们考虑问题的角度和思维的方式不可能完全一致，这增大了不同的设计内容之间的计算口径或交互方式不一致的可能性。这需要设计者们尽可能遵循一致的设计原则，也需要审阅者们尽可能找到这些不一致的地方。
3.并不是所有的程序员都适合参与设计。很明显，例如刚入职的同事就不适合参与设计，他们对系统架构还缺乏足够的认识。另外兼职的同事也不适合参与设计，他们的工作方式可能无法保证及时提交设计文档与参与讨论等。
哪些团队不适宜推行全员设计？
1.外包项目。通常承包方都会指定专门的人员与发包方进行交流和沟通，多个人员与对方交流反而可能造成沟通的不一致性，增大了交流的风险。对对方来说，更换交流人员常常意味者以往的交流工作白做了，一切都得从头再来。此外如果承包方与发包方所在国家或地区的语言不同，其中一方参与交流的必须是技术和语言的双料人才，而这样的人才通常是比较少的。
2.异地协作开发项目。当开发团队分散在不同的地方，交流的方式通常会受限于电话、即时通工具或电子邮件。这些方式都比不上面对面的讨论直接有效。设计阶段常常会产生分歧，每一方都能振振有词地说明自己的观点是有道理的。这时候就需要大家坐在一起讨论，讨论结果通常是某种程度的妥协。这种情况下，以上的几种远程沟通方式看起来都不能让大家尽快地达成一致的结论，反而会成为交流的障碍。这时由少数人来负责设计反而能减少沟通的成本，有利于保证进度的推进。
3.拥有天才设计者的项目。若项目组中有这样的天才，我们唯一能做的就是把设计的任务都委托给他了，这也是人尽其才。只是这样的天才实在是凤毛麟角。
以上是个人对于全员设计方式的一些浅见，欢迎大家讨论，敬请斧正。
