BT

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

敏捷能否分离团队和组织的关注点?

| 作者 Geoffrey Wiseman 关注 0 他的粉丝 ,译者 乔梁 关注 7 他的粉丝 发布于 2007年6月19日. 估计阅读时间: 3 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

每当谈及敏捷方法时,几乎每个人都同意这样的观点,即敏捷是可以用于软件开发团队及其所在组织的。一些人还认为敏捷方法同样可以用于那些不进行软件开发的组织,不过这不在本文范围之内。这引来了一些问题:两者到底能分开到什么程度呢?如果敏捷团队所在的组织并不希望采纳某种敏捷方法的话,团队还能取得成功吗?组织对敏捷方法的阻碍,对团队取得成功的影响到底有多大?敏捷方法是否应该只关注团队或者组织,而不顾另一方呢?

这些问题都是老生常谈了,但在敏捷联盟在重新规划自身发展方向,并提出考虑将专注于敏捷团队时,现在它们有着特别的意义:

敏捷联盟应该明确把焦点放在帮助敏捷团队的成员取得成功上,让其他人去关心那些大型组织的敏捷吧。

就像他发的“团队成功的定义”一贴一样,在敏捷论坛中,由Brain Marick发起的对其优点的支持论点、对其缺点的支持论点的帖子以及相关投票吸引了一些眼球。Laurent Bossavit为“专注于敏捷团队”大声疾呼:

我很高兴能看见一个关注“战斗在第一线的弟兄们”的敏捷联盟。只要敏捷联盟一直是在关心如何处理“前线”弟兄和业务的其它部分之间的事情,我就希望敏捷联盟的使命应该是“帮助软件开发人员融入业务,并且和业务发展齐头并进”。

而对Scott Lilly而言,这似乎是个是非分明的问题:

“局部的最优化=没有优化”

其他人则认为从整体处理是最好的方法,就像Paul Oldfield所说的:

依本人愚见,就本人经验而言,当同时既有自顶向下又有自底向上的改变,并且都是朝着共同的愿景的方向进行的时候,变化才是最有效果的。

我相信,这种方式的效果将会比只自顶向下或者只自底向上进行改变的效果的两倍还要多。

这个讨论也延伸到博客之中。当George Dinwiddie坚持认为两种关注点是不可分开的,但APLN将焦点集中在大型组织可以使得敏捷联盟将焦点更专注于团队之上的时候,他似乎持综合性态度。《从另一个侧面看敏捷(Another sideways look at Agile)》一文认为:

如果没有积极热情的业务参与的话,也就没有敏捷了。这就导致了一个问题[……]很多组织发现它们自己正站在一个处境尴尬的关口,在一个单向恶性循环中。他们并不相信他们的IT部门,因为IT部门“不能交付成果”,而这些部门不交付成果是因为需求不稳定而且很难清晰化。为了解决这个问题,他们就要敏捷地思考和行动。而这就要求他们信任IT部门,但是他们做不到,因为IT部门“不能交付成果”。

尽管有些人仍在提高他们的声音,但在别的地方对这个问题的讨论已经沉寂了。InfoQ的敏捷社区是个充满活力的大型社区,并将继续这个讨论。我们将请敏捷社区的一些人加入这个对话。但最重要的是,我们已经向我们的读者,也就是提出了问题:

  • 敏捷开发团队和敏捷组织的关注点是否能够分开考虑?
    • 他们能分开到怎样的一个程度?二者获得成功的相互依赖程度有多高?
  • 敏捷联盟应该关注敏捷团队,而让像APLN那样的组织去关注敏捷组织吗?

查看英文原文:Can Agile Separate Team Concerns from Organizational Ones?

评价本文

专业度
风格

您好,朋友!

您需要 注册一个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