对任务、系统、工作包、项目、版本这几个概念之间的关系做个初步剖析.doc

任务、系统、工作包、项目、系统版本在企业内部的IT部门中，任务/项目与系统之间通常是矩阵关系，一个项目任务涉及多个系统，一个系统同时面对多项开发要求。在这种情况下，任务、系统、工作包、项目、系统版本之间的关系是比较复杂的，而且经常由于计划变更导致它们之间的组合关系受到动态影响。为此，将这几者之间的内在关系在这里做一剖析，便于理解和运用。一、任务：来自内外部的工作要求，在一定时期内实现一定的业务、管理的目标。根据任务的工作内容相关性，可将任务分解为子任务，不同任务、子任务所包含的工作要求（需求）不应交叉。例如部门年度开发任务、部门年度重点工作任务。对于涉及应用开发的任务，根据其起因通常可分为三类：l 由于业务需求产生的需求开发任务l 由于技术手段改进产生的技术优化任务l 由于修改系统缺陷而产生的BUG修改任务二、系统：提供特定服务功能的信息系统。各IT部门都应有自己所负责管理的系统的清单，对应用系统的管理关注系统的整个生命周期的管理。开发任务与应用系统形成多对多的矩阵关系。三、工作包：任务（子任务）中密切关联并要求作为一个特定工作单元同时完成的工作内容，可视为一个工作包。在面向业务需求涉及多个系统共同开发的工作任务中，工作包位于任务和系统的交叉点，工作包的颗粒度要求是：1. 任务中包含多项开发要求时，不同开发要求可以分解为不同子任务，不同子任务可分解到不同的工作包中；2. 同一开发要求通过不同批次完成的内容，应分解为不同工作包；3. 由不同应用系统完成的开发内容，应分解为不同工作包；因此，在应用开发的任务中，工作包的颗粒度为：包含于一个任务（子任务）中的、同一批次完成的、由单个应用系统实现的功能点的集合。以工作包的颗粒度进行管理的优点在于：l 可作为范围、资源、成本管理的基本单位l 利于灵活处理工作任务的分工组合l 能支持任务、项目、系统等多口径的数据统计l 在计划、预算、实施、变更、交付、核算中提供灵活性四、项目：根据业务、技术、管理等要求，将围绕同一目标的、需要同一过程组织实施的工作包，组合为一个项目的工作内容，作为项目范围的主要内容，如：l 对应同一业务需求的l 同一过程组织实施的l 预计同一时间投产的l 对应同一厂商合同的哪些工作包应纳入同一项目，取决于工作包之间的关联性，要保证所属任务（子任务）中目标的完整性，所以通常项目与任务或子任务是对应的；如果同一需求相关的不同工作包被划分到不同项目中，则需要做跨项目的多项目管理，保证不同项目中相关联工作包的同步配合，所以通常在划分项目时应尽量避免这种情况的出现。上述任务/子任务、系统、工作包、项目的关系，如下图所示：进一步来说，无论部门内对各项任务是否经过立项纳入部门的项目管理，对于其中面向同一目标、跨系统的、紧密关联的工作包，都要保证在实施过程中的一致性和同步性。五、系统版本系统版本是针对各个系统而言的，通常对应系统每次投产时需要发布的内容，系统版本的变化反映了系统的生命周期的变化；在任务/项目与系统的矩阵关系中，同一系统经常同时面临多个工作包的开发要求，此时系统版本的组织通常有以下策略：1. 同一系统、同一项目的一个工作包的成果形成一个目标版本；2. 同一系统不同项目中的工作包形成不同的目标版本，此时可采用分支策略。即使这些版本可能同时投产，也可作为多个不同版本按顺序连续投产。这种做法的优点是可灵活应对不同项目任务计划的变化，缺点在于每个分支都需要向主线归并，每个版本都需要单独进行测试以保证各个版本可单独投产；3. 如能确定不同工作包的系统版本将会同时投产，也可合并为一个目标版本，合并后的统一版本在测试投产过程中效率会提高，但这种方式的风险在于，一旦出现不同项目任务发生变化不能同时投产，将面临系统版本分拆并需要重新测试，增大版本出错的可能性。上书第2、3两种策略，都是应对不同任务投产时间可能发生变化的策略，各有利弊。从多数实践经验看，采用分支归并的方式，相当于做加法，在工具的