敏捷已死，而敏捷性长存。

在第一块看板前，邀请一些资深同学就这块看板和它背后的“风险驱动的架构设计”方法进行了一些讨论。

同学们的意见主要集中在：

• 如何确保没有遗漏的风险？
• 知识如何积累和传承？

第一个问题。很难给出满意的答案。

目前来看，对风险的识别主要靠架构师和开发团队的经验。 如果架构师和团队经验不足，就会有风险遗漏，导致架构设计不能解决所有需要解决的问题，不能满足要求。
这个问题跟架构设计方法关系不大，不管采用何种架构设计方法，都需要首先发现待解决的问题，再去解决它。 发现问题的阶段，对架构师和团队的经验的依赖是很难避免的。 比如比较传统的三段式架构设计方法¹，是以需求驱动的架构设计方法，要求识别关键功能功能、质量场景等作为待解决的问题。 方法体系中虽然提供了一些工具和指导，但这些识别仍然依赖架构师的经验。

从另一方面讲，应该避免对风险“过度识别”。风险驱动的架构设计隐含了一个重要观点：不需要完备的架构设计。 不完备的架构设计要求掌握好一个度：识别与忽略的度。而“风险”，恰好是掌握这个度的工具。过度识别风险，把不是风险的识别为风险，等于是放弃了这个度的平衡，也就放弃了不完备的架构设计这一核心理念。

回到当前实践中，我们计划采取的措施是：制成一个风险检查清单，随时对照检查，看是或否遗漏，检查清单的来源包括但不限于：
1. 传统架构设计方法的一些现成知识，比如质量要求检查清单。
2. 企业中积累的知识，比如规章制度、相似项目的经验教训。

第二个问题。看似容易回答。

这里的“知识”主要指两方面的内容：架构设计的过程和架构设计的结果。 不管是哪个方面，其实并不是所有都需要积累和传承。

我表示计划这样来做：对于每一项风险，我们都执行了一系列的有针对性的架构任务（看板上体现为绿色的卡片），这些卡片的生命周期，其实就是对应的架构设计的过程，这些卡片的产出，其实就是对应的架构设计的结果。 当我们制定任务、绿色卡片生成的时候，我们多考虑一件事情，就是这个卡片的生命要不要记录下来，它的的产出物要不要记录下来。把考虑的结果标记在卡片上，任务完成，卡片存档的时候，我们按照这个标记制定相应地记录就可以了。

有同学对这个办法并不认可，认为知识积累和传承主要满足项目结束后的维护同事需要。从当前团队的角度来考虑某个知识是否需要记录，结果往往会遗漏。 我认为这个担忧有一定道理，但我理解“不完备架构设计”理论对这个问题的观点是：没人知道后来者真正需要什么文档，宁愿他们找不到文档，也不要走上全文档的老路。

实践中，我们会先按上述的计划做，观察一段时间再说。