模块化开发方法，首先保证了复杂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的小关键活动集合。

另外，为了保证敏捷、适应原则下的过程管理，除了传统方法的适度规范集外，更重要的是增加模块化开发的协同机制。这种开发机制，首先是基于传统过程框架下分阶段的敏捷改进，如敏捷建模、敏捷设计、敏捷开发、敏捷测试等;然后是基于敏捷思想的过程框架改进，如基于全局的需求变更管理、模型调配、进程反馈，甚至必要时的全局性迭代重启。