全员参与设计好处、风险与不适用的团队如下：

    6.2.1 全员设计可以带来以下明显的好处

    1.有助于平衡工作量，加快开发进度。详细设计的任务分解后，程序主管或核心程序员可以有更多的时间处理其它的事务，比如关注软件的开发质量或改善系统架构。详细设计的撰写任务分解后它们可以并行地撰写，这将极大地提高设计撰写的进度，节约时间。

    2.有助于培养程序员的大局观。每位撰写设计的程序员不再仅仅只关心自己负责实现的模块，他必须从更高的层次考虑和理解设计。

    3.有助于加强同事之间的交流与协作。设计者需要与系统分析员、其它程序员、审阅者进行反复的交流和沟通，实际上每份设计都是多人协作的成果。更多的沟通有助于集思广益，有助于避免一、两个人的倾向性意见导致错误的设计。每位设计者都需要对自己撰写的设计负责，他还要向其它同事的设计提供审阅意见或技术建议，彼此的工作是互相支持和依赖的，这有助于减少“只扫自家门前雪，不管他人瓦上霜”的想法。

    6.2.2 推行全员设计的潜在风险

    1.在某种意义上，全员设计可能增加交流的成本。两个人之间有一条交流途径，三个人之间最多有三条，四个人之间最多有六条。途径越多，信息量就越大，而这些信息不见得都是有用的信息。详细设计的任务分解后，不可避免地有更多的人参与交流和沟通，大家要花更多的时间来理解他人的想法，也可能要花更多的时间向他人阐述自己的观点。特别是在并行撰写详细设计的过程中，系统分析员反而可能成为另一个瓶颈了。但从总体上来看，在设计阶段花费适当的代价发现更多的问题，比在实现阶段或测试阶段再发现问题，仍然是划算的。

    2.分解后的详细设计可能引入冲突的设计内容。由于设计由不同的程序员撰写，他们考虑问题的角度和思维的方式不可能完全一致，这增大了不同的设计内容之间的计算口径或交互方式不一致的可能性。这需要设计者们尽可能遵循一致的设计原则，也需要审阅者们尽可能找到这些不一致的地方。

    3.并不是所有的程序员都适合参与设计。很明显，例如刚入职的同事就不适合参与设计，他们对系统架构还缺乏足够的认识。另外兼职的同事也不适合参与设计，他们的工作方式可能无法保证及时提交设计文档与参与讨论等。

    6.3 沟通

    在项目的开发过程中，在团队中的成员之间以及和客户之间是一个不断的交流和沟通的过程。我们的开发过程最好是一个迭代式的开发过程（尤其是国内的项目）。这样我们可以尽早发现开发出来的功能是不是符合客户的需求，以免开发完了，客户说这个不是我们需要的后果。

    6.4 计划执行控制

    制定系统得整个计划，任务的划分以及分配工作，跟踪任务的进度，使我们的项目进度在控制范围之内。

    6.5 风险管理

    风险是随着项目的不同阶段变化的，不同的阶段风险是不同的，我们必须分析我们当前面临的风险的数量、影响程度等，以及怎么去解决这些风险。

    6.6 测试

    测试工作目前在国内的中小公司做的都不太好，但是从我们做项目或者产品必须重视测试工作，把握好质量关。

    6.7 验收为目的的思想

    在开发过程中，内部管理还要注意的一点是时刻强调以验收为目的的思想，每个任务的最终可交付成果一定要是可以被检查的，比如，【界面要求：美观大方、简洁明快】，这个要求我就不知道如何检查。所以，给开发小组布置任务的时候就要考虑如何检查结果，比如我见过一个计划，里面有一个任务【开发人员熟悉EJB编程】，这个任务，除了让这些人去参加一些专业认证考试，否则，结果很难被检查。所以，时刻考虑如何检查结果、如何向客户交付是项目经理一直要注意的事情，我听说有些老项目经理拿到项目是倒排计划的，即首先看如何验收和验收标准，然后决定工作计划。很多项目开始了很久，还不知道如何验收，那么这个项目出问题的可能性就很大了。做项目就是为了验收，我们的角色不是研究机构，我们的目的就是在付出那么多劳动后得到结果。