每当谈及敏捷方法时，几乎每个人都同意这样的观点，即敏捷是可以用于软件开发团队及其所在组织的。一些人还认为敏捷方法同样可以用于那些不进行软件开发的组织，不过这不在本文范围之内。这引来了一些问题：两者到底能分开到什么程度呢？如果敏捷团队所在的组织并不希望采纳某种敏捷方法的话，团队还能取得成功吗？组织对敏捷方法的阻碍，对团队取得成功的影响到底有多大？敏捷方法是否应该只关注团队或者组织，而不顾另一方呢？
这些问题都是老生常谈了，但在敏捷联盟在重新规划自身发展方向，并提出考虑将专注于敏捷团队时，现在它们有着特别的意义：
敏捷联盟应该明确把焦点放在帮助敏捷团队的成员取得成功上，让其他人去关心那些大型组织的敏捷吧。
就像他发的“团队成功的定义”一贴一样，在敏捷论坛中，由 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?
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论