敏捷项目的主动架构

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

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

论证主动架构

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

投资组合平衡引擎
薪酬引擎
网络优化
规划或匹配引擎
有引擎的任何应用，:)
然而，敏捷已经把架构和设计文档的数量大大减少，因为它们数量过于庞大，而且存在浪费。我同意是有浪费的，但是我认为：正确的做法是创建一种新的、更精益的架构文档。放弃传统的海量被动架构文档的同时，我推荐一种新的主动架构文档，由下图中的组件对话（Component Conversation）组成:

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

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

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

用户故事：这些故事记录用户如何与应用交互，或是手动流程
组件对话：在应用组件之间的对话
技术任务：应用在组件内部要完成的技术任务
创建这些组件对话，并在整个系统层面思考思考它们，有以下效果：

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

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

组件对话示例

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

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

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

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

[1]：当[用户登录]发生时，[SuggestedFriends组件]完成[创建][建议朋友列表]通过[在所有朋友中过滤共有联系][Connection-DB组件]

[2]：当[用户点击发送朋友请求]发生时，[FacebookUser组件]完成[发送][朋友邀请]通过[选择联系邀请按钮][SuggestedFriendList组件]

[3]：当[用户点击隐藏朋友]发生时，[FacebookUser组件]完成[更新][建议朋友列表]通过[选择联系邀请按钮][SuggestedFriendList组件][隐藏朋友列表]

[4]：当[用户点击接受邀请]发生时，[FacebookUser组件]完成[接受][朋友邀请]通过[选择接受邀请][PendingInvitation组件]

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

创建这些SuggestedFriendList与用户的互动是分开的，之间有个流程。
Connection-DB被用来创建SuggestedFriendList，而且可能还包括HideFriendList。
有一个对象包含PendingInvitation组件。（而且对于其他与推迟相关的对象也可能有类似概念。）
HideFriendList可能被持久化，以确保用户选择要隐藏的建议列表不再出现。
当用户故事在后面的迭代中开发时，这些想法可能终究会出现并得到讨论，但是组件对话的优势在于：提前把它们拿出来讨论，把它们想清楚，保证它们在整个应用中以一致的方式处理。及早讨论这些组件对话，还能发现重复工作的风险，比如有些工作项在一些开发工作完成后才发现。举个例子，由于要支持的对象不同，PendingInvitation对象的设计可能会变。如果我们可以使用组件对话来尽早理解高层需求和行为，以此提供一个流程，我们能把以后迭代中重复工作的情形小化。

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

小结

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

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