BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

敏捷项目的主动架构

| 作者 Terry Bunio 关注 0 他的粉丝 ,译者 郑柯 关注 3 他的粉丝 发布于 2011年10月20日. 估计阅读时间: 9 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

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

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

论证主动架构

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

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

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

clip_image002

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

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

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

  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中文站用户讨论组中与我们的编辑和其他读者朋友交流。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

感觉Active译作主动不是很恰当诶。。 by 徐 毅

如题。。。不过也没想到更恰当的词,“活跃”感觉也不是很好,感觉active在这里有个动态的、当前的那种意思在

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT