敏捷项目的主动架构

之前我曾写过一篇博客，其中我认为使用“系统用户故事”很有必要，而且能填补一个很重要的沟壑。现在我认为：扩展用户故事，使之成为系统用户故事，并不是最佳方案。不过大家还是可以在这个链接看到那篇博客。

我仍然认为：对于某型类型的应用来说，敏捷技术还是有些问题需要解决。如果是简单的 CRUD 类应用，很可能这些附加的技术没有必要。本文是要针对比较重要的 CRUD 应用。我想我过去的错误在于：试图把灵活的用户故事理念扩展到系统故事；现在看来，这么做有点强以为之。取而代之的，我想提出的是：主动架构（Active Architecture）文档。

论证主动架构

在敏捷中，需求的焦点常常放在用户故事上。有时，用户故事和技术任务同时是重点，但不是任何架构或者整体系统设计需求。这对于 Web 应用也许可以接受，因为 Web 应用简单、琐碎，而且基本上是事件驱动的，但它不能满足有复杂后端组件的应用的要求，比如：

• 投资组合平衡引擎
• 薪酬引擎
• 网络优化
• 规划或匹配引擎
• 有引擎的任何应用，:)

然而，敏捷已经把架构和设计文档的数量大大减少，因为它们数量过于庞大，而且存在浪费。我 100% 同意是有浪费的，但是我认为：正确的做法是创建一种新的、更精益的架构文档。放弃传统的海量被动架构文档的同时，我推荐一种新的主动架构文档，由下图中的组件对话（Component Conversation）组成:

传统架构文档的问题在于：它们以被动和疏离的方式定义架构，有时类似于路线图。我建议以主动方式来定义架构。文档不应该只是定义路线的地图，而应该定义路线如何前行，并以主动方式描述路线图。传统架构文档与系统的实际行为相距甚远，似乎与系统没有多少关系，而且也没有实际效果。架构文档需要定义出架构支持哪些行为，就像用户故事支持用户使用功能一样。

用户故事有效地捕获用户和系统之间的互动，技术任务捕获系统需要完成的底层任务。可是，在这些精简的文档中，我们如何定义系统组件之间的高层互动呢？

我推荐的敏捷需求记录方式包括：

1. 用户故事：这些故事记录用户如何与应用交互，或是手动流程
2. 组件对话：在应用组件之间的对话
3. 技术任务：应用在组件内部要完成的技术任务

创建这些组件对话，并在整个系统层面思考思考它们，有以下效果：

• 用户故事与功能跨组件处理的方式保持一致
• 当以前完成的用户故事在后面迭代中再次遇到时，不会产生过多重复工作
  • 确保整个解决方案在更高层面得到透彻思考
  • 只有回过头去看以前的用户故事，才能完成某个故事——此类情况几率降低
• 技术任务在各组件之间的实现方式保持一致
• 它们可以定义复杂的后端高层需求，如果采取一个一个故事的方式，这些需求的收集会不完整，而且可能不一致
• 组件对话可以复查，以确保所有的系统功能都被覆盖到，而且不存在功能之间的缺口
  • 理想状况下采取图形方式

这些组件对话定义了解决方案的主动架构。组件对话可以采取下面这种格式：（您也可以自定义适合您特定环境的格式）：

 
[编号]：当 [事件] 发生时， [组件 A] 完成 [基本动作][对象][附加动作] 通过 [动作][组件 B] 

组件对话示例

拿几个例子来看一下，可以说明这些组件对话会是什么样子。创建组件对话的时机很重要，应该在用户故事创建完成之后，理想状态下应该是在用户故事映射（User Story Mapping）过程完成后。这些用户故事和用户故事地图能为组件对话的创建提供输入。

Facebook 有一个浏览建议朋友的函数，是用户事件驱动系统的知名范例，它可以从组件对话中获益，我们看看如何完成：

声明：这些故事只是对知名接口的虚拟表示。它们不代表实际的 Facebook 函数。

如果我们已经定义好了用户故事，我们可以创建下面这些组件对话，提供更多细节和上下文：

 
[1]：当 [用户登录] 发生时，[SuggestedFriends 组件] 完成 [创建][建议朋友列表] 通过 [在所有朋友中过滤共有联系][Connection-DB 组件]
[2]：当 [用户点击发送朋友请求] 发生时，[FacebookUser 组件] 完成 [发送][朋友邀请] 通过 [选择联系邀请按钮][SuggestedFriendList 组件]
[3]：当 [用户点击隐藏朋友] 发生时，[FacebookUser 组件] 完成 [更新][建议朋友列表] 通过 [选择联系邀请按钮][SuggestedFriendList 组件][隐藏朋友列表]
[4]：当 [用户点击接受邀请] 发生时，[FacebookUser 组件] 完成 [接受][朋友邀请] 通过 [选择接受邀请][PendingInvitation 组件]

现在，这四个故事提供了非常基本的范例，但是我希望这可以展示出组件对话捕获的信息层次。即使是这些基本的例子，我认为也捕获了下面四个想法：

1. 创建这些 SuggestedFriendList 与用户的互动是分开的，之间有个流程。
2. Connection-DB 被用来创建 SuggestedFriendList，而且可能还包括 HideFriendList。
3. 有一个对象包含 PendingInvitation 组件。（而且对于其他与推迟相关的对象也可能有类似概念。）
4. HideFriendList 可能被持久化，以确保用户选择要隐藏的建议列表不再出现。

当用户故事在后面的迭代中开发时，这些想法可能终究会出现并得到讨论，但是组件对话的优势在于：提前把它们拿出来讨论，把它们想清楚，保证它们在整个应用中以一致的方式处理。及早讨论这些组件对话，还能发现重复工作的风险，比如有些工作项在一些开发工作完成后才发现。举个例子，由于要支持的对象不同，PendingInvitation 对象的设计可能会变。如果我们可以使用组件对话来尽早理解高层需求和行为，以此提供一个流程，我们就能把以后迭代中重复工作的情形最小化。

技术任务也会从组件对话中浮现，不过只是技术任务而已，就像从用户故事中生成的功能任务。（比如：“确保 Pending 对象持久化，并支持朋友、事件和消息”，这可能是技术任务。）

小结

我在我当前的项目中使用了这些组件对话，并且大大改进了我和团队成员对项目的理解。很重要的一点是：这些组件对话不能占用太多精力和时间。我会用 1 到 2 天的时间盒确保对现有系统的一致理解。随着迭代的进行，组件对话可以修改和变更。关键是要保持精益，知道做到什么程度可以提供足够必要的价值。

这个理念为我当前的项目提供了巨大的价值。

关于作者：

Terry Bunio目前是 Protegra 的首席咨询师。Terry 以前从未想过成为项目经理，他开始时是程序员，后来发现自己对数据架构技术很有兴趣。这一路上，Terry 发现自己喜欢帮助打造团队，帮助提升客户的信任度，鼓励个人的职业成长，他也享受完成项目交付物，提供解决方案指导的过程。

看起来有人喜欢将上面的工作称为项目管理，作为一个讲求实效的项目经理，大家都知道 Terry 喜欢挑战已有假设，并努力在书上的理论敏捷与现实世界的方法之间取得平衡。

依据精益原则实施敏捷的过程，让 Terry 重新享受软件开发，并相信自己可以改变世界，他将自己视为一个再获新生的敏捷人士。Terry 实施敏捷时，喜欢依据精益原则、Green Bay Packers 橄榄球队、Winnipeg Jets 冰球队、数据架构、XML 数据库，并寻找背后的原因。

查看英文原文： Active Architecture for Agile Projects

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。