模板
教程
环境
性能
功能
管理
敏捷项目的主动架构
论证主动架构
在敏捷中，需求的焦点常常放在用户故事上。有时，用户故事和技术任务同时是重点，但不是任何架构或者整体系统设计需求。这对于Web应用也许可以接受，因为Web应用简单、琐碎，而且基本上是事件驱动的，但它不能满足有复杂后端组件的应用的要求，比如：
投资组合平衡引擎
薪酬引擎
网络优化
规划或匹配引擎
有引擎的任何应用，:)
然而，敏捷已经把架构和设计文档的数量大大减少，因为它们数量过于庞大，而且存在浪费。我100%同意是有浪费的，但是我认为：正确的做法是创建一种新的、更精益的架构文档。放弃传统的海量被动架构文档的同时，我推荐一种新的主动架构文档，由下图中的组件对话(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天的时间盒确保对现有系统的一致理解。随着迭代的进行，组件对话可以修改和变更。关键是要保持精益，知道做到什么程度可以提供足够必要的价值。
这个理念为我当前的项目提供了巨大的价值。
关于作者：
