之前我曾写过一篇博客,其中我认为使用“系统用户故事”很有必要,而且能填补一个很重要的沟壑。现在我认为:扩展用户故事,使之成为系统用户故事,并不是最佳方案。不过大家还是可以在这个链接看到那篇博客。
我仍然认为:对于某型类型的应用来说,敏捷技术还是有些问题需要解决。如果是简单的 CRUD 类应用,很可能这些附加的技术没有必要。本文是要针对比较重要的 CRUD 应用。我想我过去的错误在于:试图把灵活的用户故事理念扩展到系统故事;现在看来,这么做有点强以为之。取而代之的,我想提出的是:主动架构(Active Architecture)文档。
论证主动架构
在敏捷中,需求的焦点常常放在用户故事上。有时,用户故事和技术任务同时是重点,但不是任何架构或者整体系统设计需求。这对于 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 天的时间盒确保对现有系统的一致理解。随着迭代的进行,组件对话可以修改和变更。关键是要保持精益,知道做到什么程度可以提供足够必要的价值。
这个理念为我当前的项目提供了巨大的价值。
关于作者:
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 中文站用户讨论组中与我们的编辑和其他读者朋友交流。
评论