基于敏捷思想的重量级IT项目管理框架思考.doc
基于敏捷思想的重量级 IT 项目管理框架思考 摘 要:重量级 IT 项目具有高度复杂性和不确定性 ,以过程为基础的项目管理需要借敏捷方法加以改进。本文以阐明 IT 项目的复杂产品系统特性为起点 ,从复杂产品系统的模块化及分解入手 ,讨论了 IT 产品的动态形成过程 ,提出了一个基于敏捷开发过程的重量级 IT 项目管理框架。以提升重载方法开发效率、提高产品质量为目的 ,探讨了复杂产品分解的随机 Petri 网概念模型、柔性团队行为模型、重载方法适度规范集以及基于知识转移的敏捷开发过程 ,并提出了若干管理对策。 关键词: IT 项目管理 ;敏捷思想 ;管理框架 ;柔性团队 1 引言 软件危机推动了软件工程思想成熟 ,20 世纪 80、 90 年代 ,软件项目开始使用可重复的规范过程 ,产生了以质量管理为核心、以软件工程理论为基础的严格有序的过程管理理论体系。软件项目被定义为一个有序的、可重复的、可度量的、可严格控制的过程。 SEI 的 CMM 模型是这一阶段过程管理思想的结晶 ,而且成为一套适用面很广的通用过程实践标准。但是 ,CMM 及与其类似的 ISO9000、 SPICE等通常被认为是重载 (Heavy Weight)过程 ,其出发点是为使 软件项目能应对不可预知的变化 ,采取繁复的管理工作抵御风险。 CMM 重视系统性、制度化、文档化和度量 ,强调提高过程的可靠性、可见性、可预测性和可管理性 ,实施 CMM 要求组织在过程制度化建设上付出大量努力。重载过程的工作集中在防止和跟踪错误上 ,大量工作流程的制定 ,是为了保证项目不犯错误 ,因此 ,软件过程越来越复杂 ,越来越庞大 ,重载过程的繁文缛节、组织臃肿、办事低效、形式主义等等副作用越来越明显 [1]。重载方法与 IT 产品及其开发过程特性的矛盾日益明显 ,快速变化的外部市场环境也向传统的软件工程管理理论提出挑战。人们对软 件过程的认识日渐深刻 :软件过程不是混沌的、随机的、即兴的活动 ,也不只是一个严格有序的因果联系的工作流 ,软件项目是一个复杂系统 ,而软件过程是一种处于混沌边缘的非平衡状态下的系统行为。软件敏捷开发方法由此产生。 IT 项目敏捷开发方法 ,具有早期客户参与、快速迭代交付、自组织团队、柔性等典型特征 [2],能够提供客户满意的知识产品 ,非常适用于特定的环境 —— 高风险、不可预测和小规模的探索型软件研发项目 [3]。但是 ,软件产品的规模 (size)日益庞大 [4],重量级 IT 项目越来越多。相对而言 ,重量级 IT 项目具有较高的复杂性和不确定性 ,风险性、不可预测性也更高。传统 IT 项目开发方法及管理过程 ,导致重量级 IT 项目周期长、投入大、成果不可预期 ,较难获得客户的满意认可。重量级 IT 产品更需要运用敏捷开发方法。其中 ,重量级 IT 产品的架构、分解优化及其与柔性团队的匹配 ,是成功实现敏捷管理的关键。本文针对重量级 IT 项目敏捷管理的需要 ,提出一个基于敏捷开发过程的重量级 IT 项目管理框架 ,反映传统开发方法的敏捷性改造 ,为改进重载方法过程、提高开发效率和产品质量提供基本思路。 2 IT 复杂产品系统及其模块化 复杂产品系统 (Complex Product Systems, CoPS)指高成本的、技术密集型的、用户定制、单件或小批量生产的生产资料、系统、网络、控制单位、软件包、建筑物和服务 [5,6]。 IT 产品复杂性也日益增加 ,一方面 ,软件规模的扩展意味着功能扩展 ,这种扩展不仅仅是相同元素重复添加 ,而必然是不同元素实体的添加 ,并且多数情况下它们以非线性递增的方式交互 ,使整个软件复杂度以更大的非线性增长。另一方面 ,软件本身的技术复杂性引发了更多的管理复杂性。 Ren 和 Yeo认为 [7],IT 项目是典型的以人为中心、基于人工的 ,实质上更富个人主义色彩 ,因而难以预测、控制和自动化。因此 ,以 ERP 系统为代表的大型 IT 项目属于复杂产品系统范畴 [7,8]。 对于复杂产品系统的开发 ,一般应首先采取模块化方法进行分解 ,才能有效实现产品目标。 Simon 等提出了系统的层级特性和可分解特性以便于降低系统的复杂性 ,并研究了软件结构化设计程度与软件复杂性、多变性和改进(Enhancement)之间的相互关系 ,系统地提出了复杂产品系统的特性和划分准则[9~11]。 IT 产品的模块划分是基于对整个产品系统框架以及功能需求分析的基础上 ,将整个 IT 产品系统的研发任务按照应用技术类别 划分相对独立的模块 /子系统进行的 ,在各模块开发完成后 ,交给集成商整合为一个完整的复杂产品系统 ,在这个意义上说 ,模块化是实施复杂产品系统的前提条件或必要条件。 3 IT 产品的动态形成过程 从 IT 项目复杂性可以看出 ,IT 项目最终交付的软件产品 ,是多种知识、资源动态结合而成的知识产品。不少学者 [12]认为 ,敏捷产品是知识产品 ,产品的价值主要产生于它所包含的知识 ,而非产品的有形部分 ,同时认为过程也是一种知识产品。 Wang[13]认为 ,ERP 实施的关键是组织中系统和过程的相互适应 ,ERP 系统知识必定产生于实施 过程 ,并反映于产品之中。信息系统开发过程中 ,每一类知识的拥有主体是不同的 ,信息系统的开发过程就是这些主体之间的知识转移过程 ,信息系统的最终交付成果是这种动态交互的结果。 ERP 系统作为一种典型的 IT 复杂产品系统 ,反映了重量级 IT 项目复杂性的两个方面 ,一是最终知识产品的高度复杂性 ,是业务知识、管理模型和软件技术的综合体 ;二是知识产品生产过程的复杂性 ,即据以对用户需求的预测 ,以人为载体的多种知识、资源的相互作用、相互影响、相互结合 ,由于人的因素 ,过程管理具有较大的不确定性、不可预见性。实践中 ,IT 复杂产品系 统的第二个复杂性 ,即动态生产过程的复杂度要远远高于第一个复杂性 ,而项目成败也多决定于此 ,项目风险的控制也主要存在于此。 4 重量级 IT 项目的敏捷管理思想 IT 项目敏捷开发的需求主要表现为快速适应系统需求的变化、提高软件生产率、突出企业自身特点、支持动态联盟、面向业务目标持续改进和重组等方面。软件敏捷开发不仅仅简单地意味着软件的快速开发 ,它着重于对软件需求、过程和产品变化的灵活快速反应 ,是基于统一概念的一整套技术。和传统的软件过程有相当不同 ,敏捷软件方法是一种轻载的、基于时间的、恰好够用 (Just Enough)的、并行的和基于组件的软件开发过程 [14]。 但是敏捷方法高度的动态性、灵活性优势也形成了其应用的局限性。对于规模较大的 IT 项目 (重量级项目 ),强功能、高集成的复杂性 ,使敏捷方法的适用受到极大的挑战。而重量级 IT 项目也具备需求快速变化、业务目标实现、提高开发效率等需求 ,也需要敏捷思想的应用。目前关于敏捷管理的研究仍强调敏捷过程适用于特定的环境 —— 高风险、不可预测和小规模的探索型软件研发项目。有学者意识到了敏捷理念与传统实践的融合 ,一些 CMM 和 ISO9000的组织也开始接受部分地应用敏捷方法 [15],但是这些同时考虑项目过程的成果 ,没有引入构建过程的核心要素 —— 知识链 ,所以显得操作性不强 ,也缺乏实证。因此 ,本文提出一种重载过程的敏捷性改造 ,即基于敏捷思想的重量级 IT 项目管理方法。 5 基于敏捷过程的重量级 IT 项目管理框架 基于敏捷过程的重量级 IT 项目管理框架 ,力图达到的目标是 :依据“敏捷灵活”与“过程规范”相平衡的原则 ,解决长周期性、高集成性、功能全面性等重量级项目特性下敏捷方法的有效性。框架的核心思想是 :(1)建立复杂产品架构及系统动力学模型 ,实现复杂产品基于动态关系的分解与优化 ,导 出最优知识产品单元划分 ;(2)构造基于多智能主体的柔性团队 ,设定团队内部协同的元规则 ,设定团队功能绩效指标 ,实现外科手术式团队构建和能力评价 ;(3)基于能力的柔性团队与知识产品单元匹配 ,根据团队特性分配开发任务 ;(4)基于适度规范的过程管理 ,微观上是柔性团队的自组织迭代 ,宏观上是过程管理的规范框架 ,实现重量级 IT 项目的动态、柔性、规范。框架内容如图 1 所示。 5.1 IT 复杂知识产品的模块化分解 模块化开发方法 ,首先保证了复杂 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的最小关键活动集合。 另外 ,为了保证敏捷、适应原则下的过程管理 ,除了传统方法的适度规范集外 ,更重要的是增加模块化开发的协同机制。这种开发机制 ,首先是基于传统过程框架下分阶段的敏捷改进 ,如敏捷建模、敏捷设计、敏捷开发、敏捷测试等 ;然后是基于敏捷思想的过程框架改进 ,如基于全局的需求变更管理、模型调配、进程反馈 ,甚至必要时的全局性迭代重启。 5.5 基于知识转移的敏捷过程 Paulk 曾经提出“ XP 是 CMM 的一个截面”的理念 ,指出敏捷方法可以是规范方法的一个环节或微观表现。因此 ,“基于知识转移的敏捷过程”是基于敏捷过程的重量级 IT 项 目管理框架的核心。其中“知识转移”则强调敏捷开发过程中 ,多智能主体与知识产品之间多种形式、多种类别的知识转移活动 ,并且最终的产出是这种转移活动集成的成果。动态结合过程中 ,知识相互关系的处理 ,多主体的互动与影响等 ,都会导致最终成果的不同。 IT 项目开发中的知识转移是一个复杂过程 ,与知识主体的属性、关系、知识本身的属性等密切相关。 IT 开发过程涉及不同团队的各种知识和技术 ,专家知识分布于团队之中而不是某一个人 ,他们必须进行工作联合和知识集成去完成统一的任务。这些知识在软件开发过程中不断在智能主体间、智能主体与 产品间传递。敏捷开发过程由于强调人的主动性、适应性 ,强调团队的自组织特性 ,对知识转移的高效管理就显得尤为重要。 有别于传统基于规模的软件过程 ,基于知识转移的敏捷过程由构想、推测、探索、适应、结束等几个阶段组成 ,其结构和实施是面向时间的 ,是一种基于时间的软件开发 (Time-Based Software Development)[13]。每一次迭代有固定的时间限制 ,一个复杂的项目可被分为多个迭代和多次发放 ,需求在迭代开始时被确定 ,直至下一次迭代开始前才再次修改。 6 管理对策 根据以上管理框架 ,实践 中的管理对策主要应该采用 : (1)建立包括技术接受方和技术提供方在内的联合开发团队 ,通过培训、交流和组织 ,提升开发团队的柔性。 其中包括甲乙双方的联合开发团队是本对策的核心 ,特别在技术提供方对技术接受方的业务比较生疏、业务过程较为复杂的情况下。 (2)测评待开发产品的复杂程度及开发团队的柔性程度 ,构筑重量级项目敏捷开发基础。 产品复杂程度和开发团队柔性程度是客观的 ,理想情况下应该有客观的评价尺度 ,初始阶段可以以较大粒度定性测定。 (3)以实现高效知识转移为出发点 ,划分产品模块 ,使之与开发 团队的柔性相适应。 产品模型的划分并不唯一依据产品的复杂程度 ,开发团队的柔性程度是客观的也是相对的。因此本对策的核心是围绕建立高效的知识转移渠道。 (4)积极采用和不断开发、积累辅助工具 ,提高团队开发效率、降低团队工作强度。 规范和灵活是一对矛盾 ,利用前人的成果 ,并不断积累自身的经验 ,将会使团队以灵活的方式继承规范的过程。 7 结论 本文通过平衡“过程定义”和“灵活性” ,既考虑过程对活动的指导 ,又要保证活动与敏捷价值观的原则一致 ,提出基于敏捷思想的重量级 IT 项目的管理框架。该框架中 ,基于 重载方法适度规范集的开发协同机制是关键 ,其既要规范开发过程的活动、文档、团队行为 ,又要从全局角度协调多团队多模块的开发活动 ,还要确保收集到适当的反馈信息 ,将这些信息融入到新的迭代过程中去 ,以此实现知识转移与敏捷项目管理的结合 ,达到传统项目管理与敏捷项目管理的融合 ,实现 :拓宽知识转移的应用深度 ,拓展敏捷项目管理的应用广度。 该框架反映了重量级 IT 项目开发的敏捷思想 ,但更多技术细节尚需解决 ,如复杂项目的模块化分解方法、柔性团队的构建及行为规则、产品与标准的定义、适度规范集及协同机制等 ,均需要进一步研究给出具 体的模型、方法和机制。这是本文后续研究的主要内容。