模塊化開發方法，首先保證了復雜IT產品的降階，從分解的角度保證了項目開發的操作性;模塊化也可以提高整個產品開發的并行化，大大提高產品開發的效率;同時，通過交叉優化保證各模塊的質量，實現“一次達到目的”與傳統“反復做直到滿意”的有機結合，從而保證產品系統的質量。
傳統軟件架構理論一般基于產品功能的靜態劃分[8]，主要從信息流角度考慮模塊單元的內聚與耦合關系，更多來自于項目初期基于需求的預測和設計;而敏捷方法更關注過程中需求創新，趨于對終目標的逼近，是一種迭代更替漸進式方式。因此，此種方式下，關于知識產品的模型表述，勢必與傳統軟件架構描述方法有所不同。復雜IT項目的模塊化除了考慮終知識產品的功能特征外，還要考慮開發過程的協同與控制問題。為此可以建立IT產品基于小完備單元圖的隨機Petri網模型[16]，采用消解規則進行系統分析，靜態和動態分析相結合，有效地反映產品結構中任務執行或信息傳遞的主要特征，反映知識產品單元之間順序、并行、交叉等多種復雜的網狀動態結構關系。
隨機Petri網模型中，用變遷表示單元本身，而變遷之間的關系則代表單元之間的關系。根據每個變遷(單元)的內在特征，可形式化定義為一個七元組即{活動，輸入產品，輸出產品，前置條件，后置條件，環境，度量指標}。
從小完備單元圖出發，結合已建立的變遷(單元)間基本關系圖和建立原理可以得到小完備單元圖對應的Petri網基本模型。直接計算該隨機Petri網模型的復雜度很高，可以應用文獻[16]中提供的關系度分解技術，考察小完備單元圖的相應矩陣，將單元進行分組。然后，根據不同組內單元之間原來關系的高出現頻次進行組間連接。多層次的分解，可以形成復雜產品的金字塔型模塊結構，既包含了靜態功能信息，又反映開發過程的動態信息。
5.2 柔性多項目團隊
柔性團隊是典型的“外科手術式團隊”，其內部具有高度的柔性和靈活性，團隊成員之間有深入的溝通和密切的協作;對外則呈現高度的開發效率和運行規范，能夠進行顯性的能力評價和績效考核。柔性團隊的概念模型可以表示為
T=F(Ma， Mr， ST， C， Ms)
其中T指柔性團隊(Self Organizing Teams， or Well-Structured Teams)，是具有高度適應能力，自組織與他組織相結合的項目開發團隊。Ma指多智能主體(Multi-Agents)，即團隊成員，具備能動性、協作性的知識主體，其中包括用戶方的參與。Mr是指元規則(Meta Rules)，團隊成員相互協作溝通的基本規則集。根據復雜適應理論，該團隊系統由一群行動者組成，他們按照一套規則與其他人交流，通過探索實現目標，這其中“元規則”特別重要。它是團隊協作的基本依據，其他規則是這些元規則的不同函數。ST是共享的隱性知識(Shared Tacit Knowledge)，團隊長期協作過程中所共享的默會知識集。C是指情境(Contextual)，是柔性團隊完成具體任務時所面臨的資源、關系、環境、他人協作等狀況。Ms是指基于能力的柔性團隊度量(Measures)，度量的目的一是與模塊化的結果——知識產品單元的匹配，為產品單元尋找佳的開發團隊;二是對團隊的績效進行考評，并動態更新團隊能力表征，指導團隊的成長演化。
柔性團隊是重量級IT項目管理的基本組織單元。對于模塊化后的開發任務，一般由多個柔性團隊根據自身特質選擇相應的開發單元，并納入動態組織網絡進行管理。每個團隊的敏捷軟件開發過程必須定義每個活動什么時候、誰、在什么地方、采用什么工具協助等等具體的細節場景，同時也要根據項目的目標、團隊規模、項目關鍵程度、風險以及不確定性和客戶協作程度這些不同項目的因素對活動進行裁減和調整。除了定義單個活動以外，定義多個活動之間相互的關聯和影響，形成一個完整的過程系統也是關鍵。這需要在開發過程中定義各種場景，來說明各個活動如何結合協作。
5.3 統一產品定義和標準
復雜IT產品系統的開發強調相關模塊的兼容性。為了使模塊的開發團隊一開始考慮復雜產品各個模塊的所有因素，統一的產品定義與技術標準是系統集成研究的關鍵，是支持各模塊開發團隊工作的必要條件，使各模塊開發的專業人員有共同的語言，使用“同一種語言”進行交流。從而使各團隊能相互協作和共享信息，通過彼此及時、有效地通信和交流，盡早地發現問題并予以解決，以達到各項工作協調一致。
復雜IT產品系統統一的產品定義與技術標準包括產品功能、性能、用戶要求、開發、質量保證、進度計劃等方面，把不同階段可能出現的問題，先期加以研究制定，對產品的功能、性能、可靠性、可測試性、可維修性、可重用性等預先進行定義和標準化，使IT產品開發一次成功，避免出現大的反復。除了產品定義和標準外，多項目團隊還需要共享的知識資源等的支持，如通用的組件、構件、元素等。
5.4 重載過程適度規范集
基于優化模型的IT開發重載方法，其理論假設是過程可以通過持續的改進而提高能力，而過程是能力意味著產出結果是可預測的。以優化和預測為特征的傳統過程管理雖然無法解決軟件開發難題，但其過程管理模型和框架的規范性，是保證軟件質量的重要內容。
敏捷軟件過程主張結合企業業務，開發自己的軟件過程，這是“Just Enough”策略。該策略指出，在進行軟件過程改進時，應著重領會CMM等過程模型的精神實質和基本原理，建立適合自己的過程框架而不是拘泥于CMM等形式。在實施CMM時，必須考慮過程的多樣性，從實際出發做好文檔和過程管理，把過程管理與企業的業務目標緊密結合起來，同時探索可滿足CMM KPAs的小關鍵活動集合。
另外，為了保證敏捷、適應原則下的過程管理，除了傳統方法的適度規范集外，更重要的是增加模塊化開發的協同機制。這種開發機制，首先是基于傳統過程框架下分階段的敏捷改進，如敏捷建模、敏捷設計、敏捷開發、敏捷測試等;然后是基于敏捷思想的過程框架改進，如基于全局的需求變更管理、模型調配、進程反饋，甚至必要時的全局性迭代重啟。
