以活動為導向

任何重要的軟體開發工作都需要進行多項不同的活動：分析、使用者體驗設計、開發、測試等。以活動為導向的團隊圍繞這些活動進行組織，因此您有專門的團隊負責使用者體驗設計、開發、測試等。以活動為導向承諾許多好處，但軟體開發通常最好透過以成果為導向的團隊來完成。

傳統上，擁有大型 IT 部門 (企業 IT) 的大企業傾向於透過從矩陣 IT 組織 (職能組織) 中抽調一群以活動為導向的團隊來執行 IT 開發專案。矩陣的實線部門 (由開發、測試等副總裁領導) 通常沿著活動界線，並且將「資源」出借給虛線專案或計畫組織。這樣做的常見理由包括

• 如果所有開發人員都向單一組織 (矩陣部門) 報告，則有助於標準化開發中的慣例和技術。測試等也是如此。
• 如果所有開發人員都有長期發展/工程經理，則有助於指導、培訓和培養一般能力。測試等也是如此。
• 透過從假設可替換的開發人員、測試人員等人才庫中配置專案，有助於最大化人才利用率 (從而提高成本效益)。

然而，以活動為導向的團隊容易針對自己的活動進行最佳化，而不是針對交付有用軟體的更大目標。這是他們所負責的內容和衡量方式的結果。只有開發人員的團隊通常只會根據他們的速度來衡量。如果他們只負責交付範圍，他們不會考慮是否會解決它應該解決的問題。即使他們這樣做，他們也可能會受到產品管理團隊的阻撓 - 另一個僅負責確定規格的以活動為導向的團隊。

依活動組織會妨礙降低團隊之間移交的工作批次大小。一個獨立的測試人員團隊不會一次從開發人員團隊那裡接受一個故事。他們寧願測試一個版本價值的故事，或至少一次測試一個功能中的所有故事。這會延長回饋迴路，增加端到端循環時間，並損害整體響應能力。

高速 IT 需要有積極主動的團隊。自主性是團隊的主要動力。然而，以活動為導向的組織只能獲得如此多的自主權，因為他們傾向於使用它來優化其活動領域。

以活動為導向的組織的一種變化是超專業團隊，可能導致以下方式

• 以工具或技能為中心的團隊：例如 WebSphere Portal Server 團隊或 BizTalk 團隊
• 架構層團隊：例如表示層團隊、中間件團隊、資料層團隊。

它們是有問題的，因為它們的重點很窄，並且它們傾向於針對團隊績效進行優化，而不是大局。當然，有些工具可能需要專家，但這並不能成為將它們孤立在一個獨立團隊中的理由。專業化不是問題；沿著專業化路線組織才是。

什麼效果更好

軟體開發是一個反覆的設計過程。為了實現真正的反覆運算並實現快速回饋的價值，其活動需要盡可能由一個團隊（具有共同的報告線）執行。許多網路業務和獨立軟體供應商 (ISV) 已經以這種方式運作。

Sriram 的書更詳細地介紹了如何使用敏捷方法建立一個有效的 IT 組織。

以活動為導向的組織從最大化利用率的角度來看可能很有吸引力，但它妨礙了最大化增值和端到端響應能力。在當今的商業環境中，市場響應能力（時間效率）比成本效率更重要，尤其是在涉及軟體開發等資本支出項目時。此外，實線報告應與最重要的目標保持一致，即響應能力和增值。

為了在沒有對齊報告結構的情況下有效培養能力，請建立實務社群以及具有指導能力和組織社群活動預算的專家社群負責人，購買書籍並安排培訓。這些社群也有助於標準化慣例和技術，而不會過度標準化。至於擁有穩定的報告經理，這只在專案為中心的 IT 中是一個問題。BusinessCapabilityCentric 設定允許穩定的報告經理。