BT

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

企业架构师的敏捷策略

| 作者 Floyd Marinescu 关注 38 他的粉丝 ,译者 Jason lai 关注 0 他的粉丝 发布于 2007年4月16日. 估计阅读时间: 3 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

Scott Ambler给希望对其企业架构过程进行剪裁的企业架构师们提出了一些忠告,告诉他们怎样支持敏捷软件开发团队。文章发表在Cutter Consortium的一份企业架构师报告中,总结如下。

在文中Scott向企业架构师阐述到,敏捷软件开发团队的工作方式各不相同,作为一个企业架构师必须清楚如何使这些团队“以一种将敏捷方式反映到软件开发的方式”工作。首先Scott指出敏捷团队需要从企业架构师处得到些什么:

  • 手把手的参与。不仅仅是设计,还需要参与实际编码。
  • 对常用标准和方针直截了当的指引。敏捷团队信仰的是编码和相似的标准,但企业架构师“必须做好维持这些信仰的准备,并以合作的方式支持这些信仰”。
  • 总体概要图。“就我本人而言,我发现对于业务应用来说,一个高层次的企业领域模型、一张提供技术基础架构高层概况的UML部署图、一张自由格式的‘架构层次’图,以及一张高层企业业务流程模型总是非常有用的。”
  • 参考架构。使参考实现来阐述预期的标准和实现方式。
  • 指导。“对你组织内部的架构概念、架构、设计和其它系统的指导。”

随后,Scott阐述哪些是敏捷团队不需要从企业架构师处得到的:

  • 长篇累牍的文档。亲自上手了解要好得多。
  • 耳提面命的管理。“对于敏捷团队来说,协作方式的管理最为行之有效,命令+控制的方式只会适得其反。”
  • 审查(Review)。“审查是个‘很逊的过程’(Reviews are “process smells”);假如紧抓审查不放有意义的话,那么这意味着你很可能在项目一开始就犯下一个严重的错误。”

最后,Scott总结到:

企业架构师这些日子并不好过,因为他们不得不支持传统、敏捷以及混合型的开发团队。这也就是说,企业架构师必须能够灵活变通,并且随时准备适应即将到来的情况。开发团队则不应被要求去适应企业架构师的那一套,至少不是明显去适应。我的经验告诉我,如果让企业架构喧宾夺主,掌控了开发项目的全局,那么这个项目必败无疑(译者按:此句原文是“In my experience, the surest way to failure is to have the enterprise architecture tail wag the development dog”。英语里有这样一种说法:“The tail wags the dog”,比喻“某个不重要的事情占据了主导地位”)

您可以在Cutter Consortium注册后免费下载这份报告的PDF文档。

评价本文

专业度
风格

您好,朋友!

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

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的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通知我

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

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

讨论

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


找回密码....

Follow

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

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

Like

内容自由定制

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

Notifications

获取更新

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

BT