《架构师修炼之道》摘录09-召开架构设计研讨会

本系列内容来自《架构师修炼之道》。在自己的笔记中以半摘录的方式，用 blockquote 穿插自己的思考和感悟，以加深对内容的理解和消化。

全书整体分为三个部分

• 第一部分介绍软件架构的基础知识和架构师必备的设计思维

• 第二部分讲解架构师需要掌握的核心技能和知识

• 第三部分讨论一系列使用的架构设计方法

前两部分适合从头到尾通读，第三部分用于参考和检索。

本章学习筹划和主持架构设计研讨会。良好的主持不仅仅是举止得当，更要让讨论顺利开展。

十九世纪的法国建筑学教授会推着手推车收集学生的练习项目。就算学生觉得做得还不够好，教授也会将它收走。学生就跟着手推车，继续修改设计，这里补一点零件，那里加一根线。教授就这样带着他们去收下一个学生的项目。

十九世纪的法国建筑学教授已经明白：花更多时间并不一定能够产生更好的设计。这一理念放在今天仍然适用。用户体验社区将这一理念用到设计研讨会里，并加以推广。这种设计研讨会有严格的时间限制，旨在帮助团队在最短的时间内探索各种想法。

9.1 筹划架构设计研讨会

架构设计研讨会应该充分运用集体的智慧和经验。为了让大家在短时间内尽可能多地提出想法，你必须对设计研讨会的探索活动设置严格的时间限制，同时指导团队“先发散后聚合”——首先发散探索，然后快速聚合想法。

为了提高会议质量，让与会人积极参与并认可设计决策，应该做到设计探索的三个F——快速（fast）、有效（effective）、有趣（fun）。有趣才能提高参与度，而参与度又进一步提高会议的速度和有效性。

会议主持人要负责筹划研讨会，设法激发有价值的、可实现的想法。常见的想法分为三种：

可实现的想法。这是一类很靠谱的想法。接下来应该为它创建模型或原型，进一步充实和丰富设计。

有待评估的想法。有些想法看起来不错，但包含许多假设，或是缺少重要信息。接下来需要做实验和研究进一步评估这类想法。进一步评估后，这类想法有些会被淘汰，有些则会成为候选方案。

引发新问题的看法。有些想法提出了对正在解决的问题的新疑问。这些也是设计研讨会的成果。这些问题提前暴露出来，总比开发几周之后才发现好。我们应该带着这些问题去请教利益相关方，从而加深我们对问题的理解。

一次设计研讨会可能持续几个小时，也可能需要一整天。在某些情况下，还可以连接几天每天都召开设计研讨会。无论时间长短，设计研讨会的基本流程是相同的。

• 准备：提前了解要探索的问题。

• 启动：向团队介绍研讨会的目标和问题背景。

• 创建：制作模型、绘制草图、构建原型，通常有时间限制。

• 分享：展示创建的内容，并具体描述设计如何实现目标。

• 评判：团队对分享的内容进行评判，就设计能否完成目标发表意见。

• 迭代：重复开展第3步到第5步，优化模型，创建新模型。通常每组目标至少要迭代三次。

• 跟进：针对发现的想法、风险、问题决定后续处理步骤。

9.1.1 准备阶段

正式启动设计研讨会前要确定研讨目标，以及参会人员 。除非你理解要探索的问题，否则不要轻易召集一群人来讨论架构，那只会浪费大家的时间。

不要低估准备会议的时间，这通常要花不少工夫。你要与利益相关方沟通、做基本调研、设法确定业务目标、提炼质量属性和关键架构需求 （ASR）。召开研讨会前，你应该充分了解问题及其背景，以便有效阐述研讨目标。

定好一两个研讨目标，清楚地描述参会者在研讨会期间要探索的内容(免得开会时有人在讨论数据库的设计，而有人在讨论死锁问题)。如果开会前你对问题的理解还没有把握，那也没关系，毕竟探索解决方案可以加深对问题的理解。清晰阐述研讨目标有助于提高大家的参与度。

准备研讨会可能要几天甚至几周时间。开会前，你至少应该了解了大致的业务目标和关键架构需求。清楚项目背景和研讨目标之后，你就可以启动研讨会了。

9.1.2 启动研讨会

启动阶段将为后续研讨和协作打下基础。你应该向大家分享目前你对问题和架构的认识，确保每个人都正确了解问题背景，然后回顾研讨会要探索的内容。具体花多少时间分享背景信息要根据大家所了解的情况来定。如果有不少人是第一次接触业务目标和关键架构需求，那就应该多花一些时间做介绍。

介绍完背景后，再简要阐述研讨目标。明确的目标有助于大家在整个研讨会期间集中注意力。会议期问，每个人都要针对目标提出备选设计方案。大家还将根据目标评判这些设计方案。

9.1.3 创建、分享、评判——CSC迭代

研讨会的大部分时间都是开展CSC迭代-创建（create）、分享（share）、评判（critique）。每一次迭代都将拓展和加深我们对备选解决方案的理解。

创建

参与者针对研讨目标，独立或以小组的形式提出设计想法（画图或者建模）。用纸和笔把想法画出来是比较合适的做法，不必追求精确。在这个阶段，我们更重视想法，而不求形式上的完美。

这一步应该限制时间，通常是5到7分钟，时间宽裕的话可以相应延长。别忘了，花更多时间并不一定能够产生更好的设计！不过探索架构需要思考，对大多数软件架构问题来说，少于五分钟是肯定不够的，请根据研讨目标调整时间。

分享

创建完成后进行分享。这一步也叫游说（pitch）。每个小组有三分钟分享创建的内容，解释自己的设计如何满足目标。分享应该做到简明扼要，不需要全面展开。大家很快就会发现：创建无法分享的内容是浪费时间的。

分享时，其他人只能听，不允许提问。进入评判阶段后，每个人都有机会提问和给出意见。

评判

一个小组分享完后，其他人开始评判。评判应该围绕设计与目标的关系展开。为什么设计达不到目标？为什么设计不满足需求？这样做的目的是为建设性的对话奠定基础。

评判过程中，每个人都要就事论事，实事求是。下表列举出了评判过程中可以做什么，不可以做什么。

评判应该指出好的方面以及可以改进的地方。糟糕的设计也会有闪光点，好设计也有改进的空间。每个设计都应该得到正面的反馈和建设性的批评。所有小组都分享完后，开始新一轮的迭代。

哈哈，看到这一段内容的时候。我想起了自己曾今感受过的“研讨会”。在会议上，有的人只关注自己的想法，对他人的设计故意刁难挑刺，美其名曰“帮助完善方案”。在他人分享是，抓住方案的不足和细节不停的追问和质疑，让分享者非常难堪；而轮到自己时，面对疑问总是盛气凌人，同时对自己的方案大吹特吹，但最后方案落地时确实一地鸡毛。以至于我不再愿意参与类似的会议，因为现场和后续的过程实在是让人不舒服。

9.1.4 迭代

CSC 迭代可以促进思维的快速发散与聚合。创建阶段构思和绘制设计；分享阶段展示设计方案。评判阶段指出盲点，督促大家改进，或者尝试其他方案。

迭代能够让大家逐渐达成共识，在此基础上开展下一步的工作。在不影响研讨质量的前提下，迭代速度越快越好。

每次迭代后可以调整小组结构，这将有利于提高探索效果和参与度。如果有些人是单独一组，可以让他们结对或组成小组。如果大家已经组成小组，可以将这些小组重新混编。做好准备，通常每组研讨目标至少要开展三次CSC迭代。

9.1.5 会议总结，确定后续行动

研讨会结束前一定要留出时间让大家回顾主要议题，讨论重要的收获。此外，还要确定下一步的行动要点。哪些想法靠谱，值得进一步考虑？是否发现重大风险，需要立即解决？是否需要马上做实验？

研讨会的所有成果都应当拍照留存。趁着大家记忆犹新，赶紧做好记录。尤其重要的是记录下一步的行动要点及行动负责人，以确保按计划开展后续工作。

9.2 挑选设计方法

研讨会的主持人有责任挑选一些设计方法，引导大家快速、有效、有趣地开展CSC 迭代。已知的设计方法，但并非所有设计方法都适用于架构设计。应该考虑系统的特点，挑选那些能提高架构设计效率的方法。下表是研讨会议程的示例。

9.3 挑选参与者

参与者决定了研讨会的质量。与会者太多会增加会议成本：不合适的参与者会妨碍建设性的讨论，影响研讨的深度和质量。主持人需要在会议规模和人员多样性之间做出取舍。

9.4 会议管理

筹划和主特会议不仅仅是制订议程和把控时间， 还需要投入更多的精力。你介绍设计活动的效果将直接决定参与者的研讨效率。你的互动方式也将影响大家的积极性。主持人有责任确保研讨会达到预期的效果。

9.4.1 为研讨会留足时间

时间不够会造成设计活动过于仓促，降低参与者的信心，影响研讨会效果。如果希望会议出成果，务必留出充足的时间。

如果只有一两个小的研讨目标，那么确实有可能在一两个小时内快速完成探索。简短的研讨会只适合探索比较具体的目标，比如让团队对大体方案达成共识，为进一步完善细节打下基础。

大多数研讨目标至少需要一两天才能完成。如果大家不能很好地理解问题，那就需要在几周内举行多次小型会议。请记住，并非所有问题都适合在研讨会上探索。

9.4.2 设立期望

研讨会既要带有一点神秘性，也要让参与者了解他们要做的事情及意义。会前介绍研讨目标有助于大家快速进入状态。

会议开始前，应该宣布会议议程。当然，没必要讲得太细致。有些细节还应该保密，以免参与者产生困惑或做出先入为主的设计。如果会议时间长达几小时，至少应该宣布每个议程的开始结束时间，以便参与者可以选择是否参加某项活动。这样，大家在参加研讨会的同时，还能时不时处理一下手头的工作，不至于影响研讨会正常召开。

此外，还应该宣布参会的基本规则。下面列举了一些常见的会议规则。

• 人人参与

• 时间一到，马上进入下一个环节

• 回答不分对错

• 遇到不明白的地方，请提问

• 注意时间

9.4.3 解说-展示-再解说

介绍新设计方法时，一定要说明大家要做什么，展示一个例子，然后再回顾之前的说明。大多数人接受新事物时都会遗漏重要的细节。展示例子后再回顾之前的说明，让参与者有第二次机会就不明白的地方提问。

最好能使用以往研讨会的例子。如果没有现成的例子，可以展示类似活动的照片。

9.4.4 分享诀窍

许多人也许是第一次参加这种协作研讨会。你宣布开始后，肯定还是有人会发懵。

为了帮助新手入门，主持人可以分享参加每项活动的诀窍。简单的提醒和建议可以起到很好的作用。留意那些神情木讷的人，他们可能需要帮助才能进入角色。

9.4.5 设置截止时间

研讨会的所有活动都有时间限制。合适的时间限制能让活动开展得更快。参与者应该会感到有些紧张，但差不多总能恰好完成设计活动。理想情况下，每个活动都想“压哨球”，当你宣布“时间到”的那一刹那，小组正好完成草图！

9.4.6 适时指点参与者

除非你之前与研讨会的所有参与者都合作过，否则一定要在研讨会期间留出些时间指点某些成员，教他们一些关键的软件架构知识和设计概念。适时指点的目标是确保参与者等握足够的知识，以便顺利融入设计活动。你需要做的只是快速回顾重要的架构概念，或者简单地介绍质量属性场景。

大家的参与度对于会议至关重要，否则就不需要开研讨会了。一定要确保参与者掌握必要的知识和信息。

9.4.7 使用。停车场”

架构设计的道路蜿蜒曲折。研讨会上可能会出现一些有趣的想法，这些想法可能与当前的研讨目标无关，没时间深入探索。你可以把这些想法列成清单，我们称之为“停车场”（“parking lot”)，方便会后查看。把有趣的想法放到“停车场”里，这样不会影响研讨会的正常进行，以后有时间可以随时再做进一步讨论。

9.5 与远程团队协作

参与设计研讨会的人也许很难凑在一起。没关系，研讨会可以用远程会议的形式召开。下面是一些开展远程研讨会的技巧。

**使用远程协作工具。**这是基本条件。选好远程协作工具，外地小组才能参加研讨。研讨会可能需要一些工具才能开展，比如屏幕共享、协作文档编辑、协作、绘图、群聊、语音通话等。

**增加议程时间。**远程研讨会需要更多时间完成协作和设计活动。会议中往往还会出现技术问题。你需要提前做好准备，才不会手足无措。

**备用沟通渠道。**电话里一次只有一个人可以说话。在这种情况下，小组协作会非常困难。应该用群聊软件作为备用沟通手段。如果需要小组协作，给每个小组设好电话会议号码，并且约定截止时间，以便他们能及时回到大组讨论中来。

**准备共享资料。**参加远程会议的人很难集中注意力。主持人没法在白板上做分享，因为只有房间里的人能看到。你应该提前准备好演示材料，这样外地参与者可以在自己电脑上打开观看。讨论时，大家可以共享一个文档，所有人在共享文档上编辑、修改内容，这样每个人都能参与进来。

**创造面对面的机会。**没有什么方式比面对面互动更有效。如果可能，最好用视频会议软件，让参与者至少可以时不时看到彼此。

**离线运转。**研讨会不是探索想法的唯一方式。你可以在持续几天的时间内，以一种更慢的节奏开展很多设计活动。比如，像轮转设计这样的活动就可以通过电子邮件完成，效果也很好。

作者举一个远程研讨会的例子。主持人 Marie 来得很早，她打开屏幕共享软件，并拔通了电话会议号码。所有参与者都拨通后，Marie 启动了会议，她展示幻灯片，介绍研讨会的议程和目标。Marie 以往会把这些东西写在白板上，这次她用幻灯片也达到了同样的效果。

大家开始进行轮转设计。Marie引导参与者绘制架构视图，然后用手机拍照进行分享。所有参与者都可以通过 Slack（团队协作工具）分享草图。进入第二轮，每个人使用绘图软件对分配给他的草图进行批注，然后截屏，将原始图片和带批注的图片都共享到 Box.com （文件共享平台）上。

针对草图开展一番简短的讨论后，Marie 将参与者分成若千小组。小组用 Google Hangouts(聊天软件）进行沟通，用Box.com 创建文档，展示小组的设计想法。时间截止后，所有人重新进入电话会议，演示各小组的成果。在评判阶段，Marie 和大家在共享文档中一起做记录。这次会议持续了两个多小时，最后按时结束，这与Marie 的预期一致。如果是本地会议，大约只需要 90 分钟。

在当下新冠时期，远程协作已经深入人心。文中介绍的这些技巧已经变成一种常识。在日常工作中远程协作也已经常态化。文中补充的远程研讨会的例子，也正是当下大部分异地合作的真实写照了，区别也仅仅是使用的工具而已。

结束语

本章的内容是从一个主架构师的角度来主导架构研讨会。提到了在会议前期如何准备会议，包括会议主题、会议资料和参会人员等等，以及在会议举行过程中如何把控会议节奏，活跃会议氛围。

设计研讨会非常适合用来快速探索创意和想法。比起决策本身，研讨的过程也许更重要。所有人都参与到这个过程中，形成共同的责任感。这种责任感将在今后的工作中发挥重要的作用。 设计研讨会也有局限性。架构设计不能全靠团队协作和贴便利贴。设计研讨会本身不足以产生出色的架构设计，而且研讨会的效果很大程度上取决于筹划和组织的水平。