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

https://www.notion.so/images/page-cover/rijksmuseum_jan_lievens_1627.jpg

本系列内容来自《架构师修炼之道》。在自己的笔记中以半摘录的方式,用 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 迭代。已知的设计方法,但并非所有设计方法都适用于架构设计。应该考虑系统的特点,挑选那些能提高架构设计效率的方法。下表是研讨会议程的示例。

议程 时间 目的
介绍背景,阐述目标 15分钟 让大家积极参加研讨会,做出贡献。
轮转设计 30分钟 加快发散与聚合,让大家的头脑高速转动起来。轮转设计一般只做一轮,如果时间充裕可以多做几轮。
集体海报 30分钟 将设计结果画到海报上,便于分享。达成共识。
分享与评判 15分钟 每个小组有三分钟分享时间。采用记点投票的方法进行评判。
回顾与总结 10分钟 回顾研讨会进展情况,确定后续行动步骤。约占据10%的研讨会时间。

9.3 挑选参与者

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

a5dd5c2d52186f61

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 分钟。

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

结束语

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

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