面向活动的

任何重要的软件开发工作都需要进行多项不同的活动：分析、用户体验设计、开发、测试等。面向活动的团队围绕这些活动进行组织，因此您拥有专门的用户体验设计、开发、测试等团队。面向活动承诺了许多好处，但软件开发通常最好由面向结果的团队完成。

传统上，拥有大型 IT 部门的企业（企业 IT）倾向于通过从矩阵式 IT 组织（职能组织）中抽调多个面向活动的团队来执行 IT 开发项目。矩阵的实线部门（由开发、测试等副总裁领导）通常沿着活动边界划分，他们将“资源”借调给虚线项目或项目组织。这样做的常见理由包括

• 如果所有开发人员都向一个组织（矩阵的一个部门）汇报，则有助于标准化开发中的约定和技术。测试等也是如此。
• 如果所有开发人员都有长期服务的开发/工程经理，则有助于指导、培训和培养总体能力。测试等也是如此。
• 通过从据称可互换的开发人员、测试人员等的池中为项目配备人员，有助于最大限度地利用人才（从而提高成本效益）。

然而，面向活动的团队倾向于优化自己的活动，而不是为了交付有用软件的更大目标。这是他们所承担责任和衡量方式的结果。仅由开发人员组成的团队通常只根据他们的速度来衡量。如果他们只负责交付范围，他们就不会考虑它是否能解决它应该解决的问题。即使他们这样做了，他们也可能会受到产品管理团队的阻挠——另一个只负责确定规范的面向活动的团队。

按活动组织阻碍了降低团队之间工作移交的批量大小。一个独立的测试团队不会一次接受一个开发团队的故事。他们宁愿一次测试一个版本的故事，或者至少一次测试一个功能中的所有故事。这会延长反馈循环，增加端到端周期时间，并损害整体响应能力。

高速 IT 需要有动力的团队。自主性是团队的关键动力。然而，面向活动的组织只能被赋予如此多的自主权，因为他们倾向于利用它来优化他们的活动范围。

面向活动组织的一种变体是超级专业化团队，这可能导致以下几种方式

• 以工具或技能为中心的团队：例如 WebSphere Portal Server 团队或 BizTalk 团队
• 架构层团队：例如表示层团队、中间件团队、数据层团队。

它们是有问题的，因为它们的关注点狭隘，而且它们倾向于优化团队绩效，而不是全局。当然，有些工具可能需要专家，但这并不是将他们隔离在一个单独团队中的理由。**专业化不是问题；按照专业化路线组织才是问题。**

什么效果更好

软件开发是一个迭代设计过程。为了实现真正的迭代并实现快速反馈的价值，需要尽可能由一个团队（具有共同的汇报线）执行其活动。许多互联网企业和独立软件供应商 (ISV) 已经以这种方式运作。

Sriram 的书更详细地介绍了如何使用敏捷方法构建有效的 IT 组织。

从最大限度地提高利用率的角度来看，面向活动的组织可能很有吸引力，但它阻碍了最大限度地提高价值增加和端到端响应能力。在当今的商业环境中，市场响应能力（时间效率）比成本效率更重要，尤其是在软件开发等资本支出项目方面。此外，实线汇报应与最重要的目标保持一致，即响应能力和价值增加。

为了在没有一致的汇报结构的情况下有效地培养能力，请建立实践社区以及具有指导能力和预算来组织社区活动、购买书籍和安排培训的专家社区负责人。这些社区还有助于标准化约定和技术，而不会过度标准化。至于拥有一位稳定的汇报经理，这只是以项目为中心的 IT 中的一个问题。以业务能力为中心的设置允许稳定的汇报经理。