软件管理体系概述-ISO,CMM,CMMI

目前软件管理体系主要包括以下两个方面：ISO:9000：2000版以及CMM/CMMI下面主要介绍下面两个体系。

ISO:9000：2000版

ISO9000是国际标准化组织2000年提出的用来阐述质量概念之间相互区别与联系的指南，包括外部质量保证（ISO9001,ISO9002和ISO9003）以及内部质量保证（ISO9004）。ISO9001主要针对需要设计，加工，测试的企业，比如建筑业；ISO9002主要针对设计已经比较成熟，仅需要进行加工和测试，比如肥皂制造业（肥皂的设计是固定死的），ISO9003主要针对服务行业。由此可见软件企业是属于ISO9001体系范畴的，因为软件需要设计，开发和测试以及销售。

这些标准用于质量体系的需求的规格说明，适用于两个当事方签订合同时候要求证明供应方和提供产品能力的场合。两个当事方可以是外部客户和供应方,也可以都是内部的，例如公司的市场组和工程组。

ISO9001：2000需要由专门的培训机构来培训和相应的认证机构来认证，涉及部门为除财务部门以外的所有部门

ISO9001：2000的八大原则介绍如下：

领导：

领导者建立组织共同一致的目的及方向，他们必须创造及管理内部环境，使人员能够完全投入，以达成组织目的。

以顾客为中心：

组织依赖其顾客，故必须了解现在及未来组织的需要，必须符合顾客要求并努力超越顾客期望。

全员参与：

各阶层人员是组织的基本要素，为了组织及自身利益，他们完全参与贡献其能力。

过程方法：

管理所有活动及相关资源，有效率地达到所欲结果。

系统化管理：

鉴别、监督和管理内部相关流程且成为一个系统，提供在达成组织目标之有效性与效率。

持续改进：

组织整体绩效之持续改进必须是组织永恒的目标。

互利的供应商关系：

组织与其供应商是相互依赖并有互利关系，以增进彼此能力、创造价值。

以事实作决策：

有效的决策是以资料及资讯的分析为基础。

ISO9001：2000的八大目录如下：

范围、引用标准、术语和定义、质量管理体系、管理职责、资源管理、产品实现、测量/分析和改进。

ISO9001：2000更加给与企业的灵活性，各个企业可以按照不同的情况来制定自己的流程。只强调6个程序化文件的要求，其他程序化文件视企业情况灵活指定，但是强调《质量手册》的重要性

ISO9001：2000强调企业经营者及高层领导在体系中的作用，应有证据表明高层管理积极参与策划、实施、维护和改进质量管理体系。

ISO9000管理者代表和推行委员会或内审小组或审查小组等相关部门是ISO9000体系日常维护与完善的管理部门，通过内部审查活动及其体系改进指导或外部独立认证机构的审查，来维护监管ISO9000体系的日常运转。

CMM

CMM是设在美国卡纳基梅隆大学中的软件工程研究所（SEI）尽对于软件行业指定的成熟度标准，共分为五个等级，分别为初始级，可重复级，已定以级，已管理级以及优化级。

目前国内实施CMM的软件企业大概80%达到可重复级，已定以级,20%达到已管理级，少数企业达到优化级。

每个级别按照过程域（KPI）来实施软件的成熟度，每个级别过程域如下：

可重复级：

??? 需求管理

??? 软件项目计划

??? 软件项目跟踪和监督

??? 软件子合同管理

??? 软件质量保证

??? 软件配置管理

已定义级：

?? 机构过程焦点

?? 机构过程定义

?? 培训大纲

?? 综合软件管理

?? 软件产品工程

?? 组间协调

?? 同行评审

已管理级

?? 定量过程管理

?? 软件质量管理

优化级

?? 缺陷预防

?? 技术更新管理

?? 过程更新管理

在使用CMM时候，应该结合公司实际情况，进行合理的解释。在应用环境不同时候，需要各方面专家做出合理的意见，这一点非常重要。虽然不同公司对CMM进行了不同的裁减，但是有资料表明，90%以上的关键实践还是用上的。

CMM是软件开发和维护中有关过程管理和质量改进的一般应用。CMM代表着软件届对于好的工程和管理实践的广泛的一致认同。但是CMM也不是扳上钉钉的事情。

执行CMM需要有专门的资源和资金。一般来说包括专业技术，充足的资金和涉及到的工具。

这里的资金不是预算，而是实际提供使用的资金。

执行CMM需要对公司所有员工进行相关的培训，以便使公司员工按照指定的规章进行日常工作

对于一些专门的关键过程域需要对相关人员进行定向的培训，比如：，培训项目经理如何对软件项目的跟踪与监督。

某些关键过程域是其他关键过程域的前提，比如只有建立了软件项目计划才能够执行软件项目的跟踪与监督。

实行CMM需要根据需要成立如下小组，小组成员可以兼职，也可以专职，一般来说需要成立以下小组：

主要的小组：

系统工程组：负责软件设计开发的小组；

系统测试组：负责软件测试工作的小组；

培训组：??? 负责培训公司员工以便CMM的执行

Scrum与ISO9001、CMM和CMMI的关系

ISO9001、CMM和CMMI的概念

ISO9001是一个国家标准，即《ISO9001：2000质量管理体系--要求》。ISO9001标准起源于制造业，其标准结构、质量体系特点都与制造业非常吻合。随着市场经济的发展和市场竞争的

愈加激烈，除了机械、电子、汽车、建筑等传统产业的企业认为ISO9001质量体系认证必不可少外，其他行业，如IT、通信、服务业（酒店、物业管理等）等也在如火如荼地推行ISO9001

认证。
而CMM是由美国卡内基.梅隆大学的软件工程研究所（SEI）开发的软件成熟度模型，美国的软件企业往往选择取得CMM等级证书。
在形式上，CMM分为5个等级（第1级别最低，第5级别最高）：

初始级
可重复级
已定义级
已管理级
优化级

与ISO9001审核后只有“通过”和“不通过”两个结论相比，CMM是一个动态的过程。企业在取得低级别证书后，可以根据高级别的要求确定下一步的改进方向。在基于原理方面，

ISO9001和CMM都十分关注软件产品质量和过程改进。尤其是在ISO9001标准增加了持续改进、质量目标的量化等方面的要求后，它在基本思路上和CMM更加接近了。
而所谓的CMMI是在CMM的基础上相继开发出系统工程、软件采购等各方面的能力成熟度模型，并整合而成的一种更为复杂、宏大的模型系统，但基本思想和CMM是没有

很大区别的.....

Scrum与之的不同点：

ISO9001以及CMM和CMMI，这些都是比较接近的或者类似的软件管理模型方法。而这些方法相对于Scrum这种敏捷的软件开发管理方式而言，还是有比较大的区别。比如，CMM等

强调过程的可观性，Agile则强调可观测的结果（可运行的软件），CMM等比较强调文档，而Agile却不是那么在乎文档等。

敏捷软件开发模型SCRUM介绍

一什么是Scrum?

Scrum (英式橄榄球争球队), 软件开发模型是敏捷开发的一种，在最近的一两年内逐渐流行起来。

Scrum的基本假设是：

开发软件就像开发新产品，无法一开始就能定义软件产品最终的规程，过程中需要研发、创意、尝试错误，所以没有一种固定的流程可以保证专案成功。Scrum 将软件开发团队比拟成橄

榄球队，有明确的最高目标，熟悉开发流程中所需具备的最佳典范与技术，具有高度自主权，紧密地沟通合作，以高度弹性解决各种挑战，确保每天、每个阶段都朝向目标有明确的推进。

Scrum 开发流程通常以 30 天(或者更短的一段时间)为一个阶段，由客户提供新产品的需求规格开始，开发团队与客户于每一个阶段开始时挑选该完成的规格部分，开发团队必须尽力于

30 天后交付成果，团队每天用 15 分钟开会检查每个成员的进度与计划，了解所遭遇的困难并设法排除。

二 Scrum较传统开发模型的优点

Scrum模型的一个显著特点就是响应变化，它能够尽快地响应变化。下面的图片使用传统的软件开发模型(瀑布模型、螺旋模型或迭代模型)。随着系统因素（内部和外部因素）的复杂度

增加，项目成功的可能性就迅速降低。

下图是Scrum模型和传统模型的对比：

三 Scrum模型

一) 有关Scrum的几个名词

backlog: 可以预知的所有任务，包括功能性的和非功能性的所有任务。

sprint:一次跌代开发的时间周期，一般最多以30天为一个周期.在这段时间内，开发团队需要完成一个制定的backlog,并且最终成果是一个增量的，可以交付的产品。

sprint backlog:一个sprint周期内所需要完成的任务。

scrumMaster: 负责监督整个Scrum进程，修订计划的一个团队成员。

time-box: 一个用于开会时间段。比如每个daily scrum meeting的time-box为15分钟。

sprint planning meeting: 在启动每个sprint前召开。一般为一天时间（8小时）。该会议需要制定的任务是：产品Owner和团队成员将backlog分解成小的功能模块, 决定在即将进行的sprint

里需要完成多少小功能模块，确定好这个Product Backlog的任务优先级。另外，该会议还需详细地讨论如何能够按照需求完成这些小功能模块。制定的这些模块的工作量以小时计算。

Daily Scrum meeting：开发团队成员召开，一般为15分钟。每个开发成员需要向ScrumMaster汇报三个项目：今天完成了什么？　是否遇到了障碍？　即将要做什么？通过该会议，团队

成员可以相互了解项目进度。

Sprint review meeting：在每个Sprint结束后，这个Team将这个Sprint的工作成果演示给Product Owner和其他相关的人员。一般该会议为4小时。

Sprint retrospective meeting：对刚结束的Sprint进行总结。会议的参与人员为团队开发的内部人员。一般该会议为3小时。

二）实施Scrum的过程简单介绍

1) 将整个产品的backlog分解成Sprint Backlog,这个Sprint Backlog是按照目前的人力物力条件可以完成的。

2) 召开sprint planning meeting，划分，确定这个Sprint内需要完成的任务，标注任务的优先级并分配给每个成员。注意这里的任务是以小时计算的，并不是按人天计算。

3) 进入sprint开发周期，在这个周期内，每天需要召开Daily Scrum meeting。

4) 整个sprint周期结束，召开Sprint review meeting，将成果演示给Product Owner.

5) 团队成员最后召开Sprint retrospective meeting，总结问题和经验。

6) 这样周而复始，按照同样的步骤进行下一次Sprint.

整个过程如下图所示

怎样的设计流程才高效，精确，快捷？

建立敏捷统一过程框架我建议，软件企业可根据自身的实际情况，以统一过程（如 RUP）为基础建立起符合ISO 9001、SW-CMM 和CMMI SE/SW等基准的组织软件过程体系，同时包含敏捷过程（如XP、

Scrum）和重型过程（如TSP）等内容。我把这种混合/集成过程体系叫做“敏捷统一过程框架”（Agile Unified Process Framework，AUPF）。 
一、过程成熟度与多样性

近年来软件过程改进在国内日益得到重视，一度出现了许多组织纷纷开展 SW-CMM 商业评估的热潮。迄今全国已有近两百家软件企业通过了 SW-CMM、CMMI 各级评估（1 2 3）。这一方面说明原本作

为美国军方标准（如今已成为全球通行的国际标准）的 SW-CMM、CMMI 并非高不可攀，另一方面也说明加强软件开发规范化管理、提高过程成熟度已经得到了业界的广泛认同。

 
与此同时，国际软件界的“敏捷热”、“统一热”也在持续升温。上世纪 90年代以DSDM、Scrum、FDD、Crystal、ASD、XP为代表的轻型软件开发方法逐渐兴起，其中又以XP对传统的“反叛”最

为显著，它凭借与传统思维相悖的“极端”做法既获得了许多软件客户、管理者和开发人员的积极拥护，也遭到了传统过程维护者的激烈反驳。2001年2月敏捷联盟成立以及《敏捷软件开发宣言》的发

表，标志着这场“敏捷运动”达到了一个高峰。而作为吸收了电信、国防等关键行业以及IBM、HP、Microsoft等多家国际著名软件企业过程经验的商用过程产品，统一过程RUP也在

全球取得了广泛的成功。某著名咨询机构 2002 年对全球200位软件相关行业IS/IT经理进行的调查表明：RUP使用率达到了51%，远高于SW-CMM（27%）和ISO 9000（26%）；而且到2003年, 大约50%的

被调查者预计其50%以上的项目会使用敏捷方法，14%的被调查者认为其所有的项目会使用敏捷方法 [2] 。

承认软件过程的多样性与追求其成熟度一样重要。“ One size does not fit all ”，事实证明不存在一成不变地适合于所有项目的过程模板。由于软件过程的周境不同（如业务、资源、团队、文化），

层次不同（如组织过程、项目过程、团队过程、个体过程），开发类型不同（如新产品、重用、服务、产品线），一时间出现这么多过程方法论并不足怪。

二、过程方法论对比分析

那么，敏捷、统一过程有哪些特点，与传统过程有什么不同呢？下面我们以 SW-CMM 为参照，挑选 3 个最典型的过程方法论（ XP 、 RUP 和 TSP ）作对比分析。

SW-CMM是一套用来评估软件组织过程成熟度的基准，阐明组织为了系统地实施软件过程改进、提高过程成熟度应该做些什么，但没有规定如何去做。它的目标通常适用于所有的软件组织或项目，用来实现目标的

大部分关键做法也适合中小企业项目，而许多关键做法中的子做法主要目的是举例说明如何在大型政府、国防合同项目中实现总目标，对中小企业项目仅有参考价值。除了对过程的集成性关注不够，SW-CMM的主要

缺点还在于缺少了现代软件过程的一些重要元素，其KPA主要集中在传统过程的静态文档上（如设计、需求文档，合同、计划和报告等），只有很少数的KPA强调了演进式工件（如需求、

设计模型，源代码等）、开发环境的自动化水平以及基于架构的过程。 [6]

为了尽早通过评估，人们往往采用或模仿同样是由SEI开发的PSP/TSP过程。建立在PSP之上的TSP可能是迄今为止最为严格的重型过程。为了提高过程的成熟度和可预测性，TSP强调对过程

进行全面精确的度量，这依赖于制作大量复杂繁琐的数据表格和文档以及固定程式化流程配合，因而培训、实施的成本很高。

RUP是一个以用例驱动、构件式架构、迭代递增式开发为基本特征，可广泛地应用于各种类型和规模项目的软件过程框架，它的基本特征与需求管理、配置变更管理、OOAD*UML可视化建模、

持续检验质量等做法一起集中体现了现代软件开发的最佳实践。RUP定义了起始、细化、构造、移交4个阶段和业务建模、需求、分析设计、实现、测试、部署、配置变更管理、项目管理、环境等9个

工种。阶段对应着主里程碑的划分，不同工种的工作流活动在生命周期的迭代中并发进行，具体执行强度可以按需调节，角色、活动和工件也是灵活可配置的。由于RUP提供了极其丰富的内容，所以常

被误解为一个重型过程。通过定制RUP通用框架，针对具体项目去掉不必要的元素并吸收其他敏捷方法，完全可以定制出敏捷轻型的RUP过程（如RUP的XP插件）。

极限编程 XP具有强沟通、简化设计、迅速反馈等特点，一般只适合于规模小、进度紧、需求不稳定、开发小项目的小团队。在其12种做法中，测试为先、持续集成、简化设计、代码规范、现场客户、每

周40小时工作制、小型发布等早已有之，并不是新的发明，但XP通过巧妙整合把它们发挥到了极致。而代码集体拥有、结对编程、重构、系统隐喻、计划游戏等做法并不是在任何情况下都适用的，使用不

当往往会起到相反效果。SW-CMM与XP是互补的，Barry Boehm、Watts Humphrey等权威更认为XP与SW-CMM是哲理相容的 [5] 。主要区别在于，后者更关注过程实施在组织管理上的问题，而XP侧重

于具体的过程执行和开发技术，不含有被SW-CMM认为是使良好的工程和管理实践制度化的关键基础设施。

许多团队在一定条件下实践 XP可能会收到意想不到的好效果，但纯而又纯的XP的适用面可能也很小。克莱斯勒公司的C3薪资系统项目恐怕是引用次数最多的XP成功案例，但实际上该项目后期还是由于开发

团队与管理者之间的沟通出现问题而遇到了麻烦。一个经典的XP项目偏偏在其核心的沟通要素上出现问题，的确值得人们深思。 [7]

XP以代码为中心，编码和设计活动融为一体，弱化了架构，这是它与以架构为中心的RUP的最大不同，而且它没有业务建模、部署、过程管理等概念。两者也有不少共同点：它们都采用OO技术（取代传统结构

化方法）、演进式迭代周期（取代传统瀑布模型），强调风险驱动，以保障可用产品的持续性交付为前提，尽量减少不必要的过程工件，使度量、文档最小化以获得弹性和应变能力。由于RUP、XP结合了具体的

开发方法，因此比TSP具有更好的可操作性。敏捷、统一过程满足了 SW-CMM绝大部分目标及2、3级KPA的要求，对4、5级KPA基本没有涉及。然而，服从类似SW-CMM这样高质量的过程框架，并不一定会开发出

高质量的产品，生产出高质量产品的真正高质量的过程却理应被评估为成熟的过程 [6] 。事实上，国际上不少采用RUP的组织已经达到或超过了SW-CMM 3级的水准。通过SW-CMM评估要求组织在过程制度化建

设上付出大量复杂、高成本的努力，但过程改进的有效性与复杂性、高成本之间没有必然联系。过程选择的多样性和SW-CMM目标的通用性决定了过程改进途径的多样化。

Scrum 与CMM/CMMI 与ISO9001冲突吗

CMM 敏捷开发制造领域模型设计模式

公司去年下半年刚刚通过CMM5 认证，对于国内企业来说，通过这个认证需要相当的实力和软件管理水平。当然，从软件管理上来讲，我们采用的是传统的瀑布模式，但是目前我们也想在公司的一些部门推广使用敏捷的办法，尤其是Scrum。公司现有的规章制度不能改变，还是要严格遵守CMM/CMMI 的一些要求，我不是特别清楚Scrum 与CMM/CMMI 的关系，另外还有ISO9001的这样的质量标准，他们之间有冲突吗？
ISO9001 是一个国际标准，即《ISO9001：2000 质量管理体系——要求》ISO9001标准起源于制造业，其标准结构、质量体系特点都与制造业非常吻合。随着市场经济的发展和市场竞争的愈加激烈，除了机械、电子、汽车、建筑等传统产业的企业认为ISO9001 质量体系认证必不可少外，其他行业，如IT、通信、服务业（酒店、物业管理等）等也在如火如荼地推行ISO9001 认证。而CMM 是由美国卡内基·梅隆大学的软件工程研究所（SEI）开发的软件成熟度模型，美国的软件企业往往选择取得CMM 等级证书。
在形式上，CMM 分为5 个等级（第1 级级别最低，第5 级级别最高），与ISO 9000审核后只有“通过”和“不通过”两个结论相比，CMM 是一个动态的过程，企业在取得低级别的证书后，可根据高级别的要求确定下一步的改进方向。在基本原理方面，ISO9001 和CMM 都十分关注软件产品质量和过程改进。尤其是在ISO 9001 标准增加了持续改进、质量目标的量化等方面的要求后，在基本思路上和CMM 更加接近。而所谓的CMMI 是在CMM 的基础上相继开发出了系统工程、软件采购等各方面的能力成熟度模型，并整合而成的一种更为复杂、宏大的模型系统，但基本思想和CMM是没有很大区别的⋯⋯
ISO9001 以及CMM 或者CMMI，这些都是比较接近或者类似的软件管理模型方法，而这些方法相对于Scrum 这种敏捷的软件开发管理方式而言，还是有比较大的差别的。比如，CMM 等强调过程的可观测性，Agile 则强调可观测的结果（可运行软件），CMM 等方法比较强调文档，而Agile 方法却不是那么在乎文档等。
总体而言，CMM/CMMI 与Agile 是两种不同的软件研发管理和过程体系，前者比较重量级，后者更为轻量一些。Agile 包含了更多具体、实用的软件工程技术方法，而CMM/CMMI 提供了更多以数学统计为基础的过程管理和质量控制技术方法。但是这并不是说Scrum 在一个CMM 管理的企业中一定会带来冲突。
我认为，合理、恰当的结合运用Scrum 以及CMM 的一些管理理念是不会有太大问题的。因为在很多软件过程中，使用Scrum 能够在一些专门的领域大大减少工作量，比如修改Bug、软件设计等方面。也就是说，可以在大的、更为宏观的层面上使用CMM 来控制质量和管理流程，而在一些小团队的具体分工中采取Scrum 这样的敏捷方法。所以，从总体上说，在实施层面上Scrum 与CMM/CMMI 应该是兼容的。但是从价值观来看，敏捷和CMM/CMMI 又是冲突的。CMMI 的价值观是过程重于人，文档重于可运行的软件。敏捷则正好相反。敏捷是要消除一切阻碍创造价值的浪费。而在CMMI 的大量关键过程域中，只有很少的东西和开发有关，大多数CMMI 的实施都会带来很大的浪费。另一方面，CMM/CMMI 不关心团队协作，不关心是否能招到合适的人，更不关心你的代码是否应该重构⋯⋯
在以后的时间里更深入地研究、实践这个问题，甚至是一些更为细节的管理问题，比如CMM 要求的文档的问题Scrum 团队应该如何应对等。我想应该可以找到一个很好的平衡点。

SCRUM软件开发过程

这些天看到一本书《Agile Project Management with Scrum》，感觉很不错，于是在网上找了些相关的资料。

SCRUM方法如下：

由Ken Schwaber和 Jeff Sutherland 提出，旨在寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进，名称来自英式橄榄球（在比赛中每个队员都应时刻保持对场上全局的判断，然后通过集体行动，奋力实现同一目标──胜利）。SCRUM方法最初实践于Easel公司(1993年)，现已被数十家公司数百个项目开发中应用，适用于需求难以预测的复杂商务应用产品的开发[11]。SCRUM提出的SCRUM Meeting、Sprint、Backlog、SCRUM Master、SCRUM Team、Demo等模式已被PLOP作为组织和过程模式（Organizational and Process Pattern）的标准[12]。
SCRUM将工业过程控制中的概念应用到软件开发中来，认为软件开发过程更多是经验性过程(Empirical Process)，而不是确定性过程(Defined Process)。确定性过程是可明确描述的、可预测的过程，因而可重复（Repeatable）执行并能产生预期的结果，并能通过科学理论对其最优化。经验性过程与之相反，应作为一个黑箱（Black box）来处理，通过对黑箱的输入输出不断进行度量，在此基础上，结合经验判断对黑箱进行调控，使其不越出设定的边界，从而产生满意的输出。SCRUM方法将传统开发中的分析、设计、实施视为一个黑箱，认为应加强黑箱内部的混沌性，使项目组工作在混沌的边沿，充分发挥人的创造力。如将经验性过程按确定性过程来处理（如瀑布模型），必将使过程缺乏适应力。
3.2.1 SCRUM方法的开发过程
包括三个过程：
(1) 计划和体系结构设计（确定性过程）
将Backlog（急待完成的一系列任务，包括：未细化的产品功能要求、Bugs、缺陷、用户提出的改进、具竞争力的功能及技术升级等）按优先级排序形成Backlog 列表，根据该表和风险评估制订产品交付基线。
建立系统体系结构（如为已有系统改进，则只作有限分析、调整），将Backlog项按高内聚低耦合的原则分解为一系列问题包(Packets,每个Packet是一组对象或构件的集合) ，依据同样原则相应划分若干个开发小组（SCRUM 小组）,分配各小组合适的Backlog项或问题包。建立开发运行环境。
(2) Sprint（经验性过程）
该过程由若干个迭代的冲刺(Sprint) 活动组成，直至风险评估认为产品可交付为止。一个Sprint是在限定时间段内（Sprint周期，通常为1~6周，可在前一个Sprint结束时调整）的一系列开发活动（包括分析、设计、编码、测试等），每个SCRUM小组并行开发且必须步调一致（在一个Sprint结束后，均须完成所分配的Backlog项并有可执行的产出）。
每个Sprint包含以下活动：
l 开发。对分配的Backlog工作进行分析，将所需改动（changes）映射到各packets，打开packets,进行领域分析，然后设计、开发、实施、测试、文档化这些改动。
l 打包(Wrap)。封装packets,产生一个满足Backlog需求的可执行版本。
l 评审（Review）。所有的SCRUM小组一起开会，提交各自的工作并演示(Demo)，然后提出和解决问题(Issue)及难点（problem）,增加新的Backlog项；发布、审查或调整产品的标准规范；进行风险评估并提出合适的对策；确定下一个Sprint的工作内容和结束时间。
l 调整（Adjust）。根据评审会汇集的信息，对受影响的Packets进行适当调整和巩固。
(3) 交付和巩固（确定性过程）
一旦根据风险评估结果认为可交付产品时，即进入该阶段。该阶段的活动包括：组装，系统测试和回归测试（Regression），准备培训材料，完成最终文档。
SCRUM过程认为一个产品的开发将一直持续下去，除非经风险评估后认为应停止。产品交付后的巩固活动类似于传统方法中的维护和改善，目的在于整理Sprint期压力下忽略的工作，为下一阶段的开发做准备，以便轻装上阵。
3.2.2 SCRUM对过程的管理：
(1) SCRUM的控制手段。
SCRUM提出了八个控制项（Controls）用于开发过程的调控，其中风险控制是首要的手段。
l Backlog。
l 对象/构件。
l Packets。
l 变动（Changes）。实施一个Backlog项时，对相应Packet的改动。
l 难点（Problems）。实施一个变动时所必须解决的技术难点。
l 问题（Issues）。涉及到整个项目或在Backlog项分解到Packet之前须解决的问题。
l 措施（Solutions）。对问题或难点的解决，通常会导致变动。
l 风险（Risks）。影响项目成功的风险，应持续跟踪评估并相应做出调整。风险评估的结果将影响其他所有控制项。SCRUM定义了六个概念性变量来用于风险评估：用户需求，时间压力，竞争，质量，远见（vision）和可用资源。
在SCRUM的各个阶段都使用这些控制项来评估和权衡，管理人员侧重于以此管理Backlog，开发组用以处理变动和难点。所有人员一起来管理问题、风险和措施。
根据对控制项特别是风险的不断度量评估和权衡，一方面，计划和进度（在每个Sprint结束时）不断相应调整，保证实现产品的商务目标；另一方面，对开发中的工作任务Backlog动态地进行优先级排序，开发组总是先开发优先级最高的Backlog项，这样就保证了资源的最合理使用。另外，SCRUM强调度量（采用标准功能点度量方法）的重要性，通过对每个Sprint中生产率等的度量，计划和进度将越来越趋于准确。
(2) 项目组织。
项目组由全职开发人员及与该交付产品有关的市场人员、销售人员、用户等组成。设以下小组：
l 项目管理组。由产品经理领衔，包括总设计师，各SCRUM小组组长，市场、销售的高级职员及典型用户等。
l 若干个SCRUM小组。各小组由组长（SCRUM Master）领衔。每个小组都是跨专业的（通常包括开发人员，文档人员，质量控制人员或用户代表等），通常为3~7人，以使小组内有充分的交流。小组的划分最好是功能导向的（按所分配的问题包或Backlog），也可是系统层次导向（按体系结构中的分层）。.
在项目组人数增大时，可在管理组之上再设管理组（SCRUM of SCRUM）,从而使SCRUM方法的应用到大项目中。
(3) Sprint期间的调控。
在Sprint期间，应使各SCRUM小组尽量避免外界的干扰（不可将新的Backlog任务加进来，组内产生的Backlog可放到整个项目的Backlog列表中，也可在本次Sprint中解决），使小组成员专心于目前的工作，使他们工作在混沌的边沿。
为避免项目组在Sprint期间不陷入混乱，SCRUM采取两个措施:
l SCRUM会议（SCRUM Meeting）。对小组行为进行监控和刺激。会议在Sprint期间每天在同一地点举行，由SCRUM Master主持。会议上，SCRUM Master对每个小组成员提三个问题：
1）昨天的工作进展如何。
2）有否遇到困难和障碍。
3）今天的工作打算。
会后SCRUM Master集中精力排除障碍，小组成员则进行当天的开发。
l Sprint评审会议。评审后根据对每人的工作成绩，进行相应的激励。
3.2.3 SCRUM方法的实践效果和发展方向：
SCRUM在实践中大大提高了生产率（据软件生产率组织的Capers Jones称可提高6倍），在实施中有一个"间断平衡"（Punctuated equilibrium）现象（类似于自然界中物种的进化，在经过一段相对平衡的各自独立、并行的发展期后，在交汇处发生变异），即在经过紧张、并行的Sprint开发后，在Sprint评审时，软件产品产生较剧烈的变化。SCRUM方法的最近动向是设法借鉴XP方法。

开源项目管理软件(scrum管理工具)禅道发布1.0 rc1版本

添加时间： 2010-04-19 09:33:49 作者：王春生 来源：本站原创 阅读：9180

大家好，我非常高兴的向大家宣布，开源项目管理软件——禅道管理(ZenTaoPMS)正式发布1.0 rc1版本。该版本的发布，使得禅道距离正式版又近了一步。

一、下载地址：

1. 源代码包：http://zentaoms.googlecode.com/files/ZenTaoPMS.1.0.rc1.zip
2. windows集成安装环境：http://zentaoms.googlecode.com/files/ZenTaoPMS1.0.rc1.exe
3. fedora12安装包：http://zentaoms.googlecode.com/files/ZenTaoPMS-1.0.0rc1-2.fc12.i686.tar.gz

二、本期主要改进地方：

2.1 完善了删除机制。
2.2 完善了多公司的支持。
2.3 完善了界面的UI。
2.4 增加了列表的导出csv功能。

具体的需求列表：

story#200 完善删除功能
story#196 应该给燃尽图增加链接
story#183 安装时尝试写入配置文件
story#198 切换产品或者项目时，能够记住之前选择的菜单
story#208 记录对发布的修改记录
story#199 增加需求、任务、bug和用例的快速跳转
story#205 完善对产品操作的历史记录
story#210 列出对某一个todo历次的修改
story#219 完善对多公司的支持
story#207 记录对build的修改记录
story#204 通过关联需求修改某一需求所属计划时，应记录相应的操作记录
story#209 记录对项目的历次修改
story#197 解决列表页面字段重叠问题
story#206 完善对产品计划管理的历史记录
story#189 增加导出为csv格式的功能

三、如何安装

3.1 windows用户：推荐使用集成运行环境，请参考 http://www.zentao.cn/node78771.html
3.2 使用zip包安装：

3.2.1. 首先安装apache, php, mysql的运行环境。linux平台可以考虑 xampp: http://www.apachefriends.org/zh_cn/xampp.html
3.2.2. 将ZenTaoPMS下载下来之后，解压缩apache的www或者htdoc目录目录。
3.2.3. 通过浏览器访问 zentaopms/www/index.php，系统会自动转入安装程序，然后按照提示进行就可以了。

四、如何升级

4.1 解压缩最新的程序，覆盖原来的版本。如果使用rpm包升级，请通过yum localinstall xxx.rpm --nogpgcheck
4.2 访问zentaopms/www/upgrade.php，选择对应的版本，按照提示进行即可。
4.3 升级之后，注意需要给用户新增权限，这次主要增加了产品详情，csv的导出，测试任务中的用例列表等。
4.4 windows下面的集成环境用户升级请注意，只需要下载最新的zip格式的源代码，将其解压缩到home/zentao/目录下面，然后访问http://xxxx/zentao/upgrade.php，即可。如果你原来使用的是静态url地址的方式，还需要修改home/zentao/www/.htaccess文件，将其中的RewriteRule (.*)$ index.php/$1 [L] 改为 RewriteRule (.*)$ /zentao/index.php/$1 [L]

UML软件工程组织

火龙果软件工程技术中心

更多技术资源文章，讲座 ,培训，咨询请访问 www.uml.org.cn

Scrum工具大比拼---流行Scrum工具一网打尽

2008-11-05 来源：blogspot.com

早就想写这个总结了，因为SCRUM很好，工具却难找，但一直没有出台，是想等自己都试用过后，这样才更有发言权。可有些工具真的是很难搭起一个环境，这样只好摘录一些网友们的评论了！ ---敏捷精灵

白板

最直接的方式，用于每天的tracking，还是非常不错的，但是对Product Backlog支持明显不够

Excel

我们最初也用过，主要是成员多的情况下，修改时会相互冲突，不好同步。。可以参考我写的这个文章[scrum工具]用excel表格工具实现Scrum

ScrumWiki

这个也用过，一开始感觉还不错。但当你的需求变多变复杂的情况下，就不容易用了。后台脚本使用Perl写的，我们的一个外国同事还对他专门进行了修改，增加了好多feature,这样才好用起来。作为免费的软件，目前已经没有人支持和维护。

Scarab

Java server 平台, 支持灵活定制，免费

Double Chocco Latte

基于PHP , 支持Apache 或IIS, MySQL or SQL Server , web 客户端，免费

VersionOne

商业化产品！没什么好说的，业界老大！

从功能上看，的确非常新颖，贯彻了敏捷中的User Story为先的原则，和VSTS类似，将Issues、Defect、Task合并概念成为Task(在VSTS中更加优雅，叫做WorkItem)，并且必须挂在UserStory下，这个工具值得看看，有试用版可以下载，或者可以使用他们在线提供的试验平台

基于ASP.NET and IIS和 SQL。

团队可以使用“V1：敏捷团队”来管理产品和sprint backlog，通过交互式的“任务板（taskboards）“和"测试板（testboards）" 进行每日开发活动，藉由报表和燃烧图查看进度，以及其他活动。

通过这些功能，“V1：敏捷团队”的用户可以做到：

从电子表格中快速导入故事与缺陷，管理合并后的产品backlog。
利用简单的多条目拖放操作，方便地完成计划制定、对故事划分优先级。
使用电子白板界面同时制定多个版本的发布计划，提高效率。
通过交互式的任务板（Taskboard）、测试板（Testboard）、每日Scrum dashboard来对版本和sprint进行可视化追踪。
针对版本和sprints的关键敏捷度量数据生成图表，如Burndown、Velocity、Estimate trends、Cumulative Flow Reports。

唯一的问题就是提供的选择过多，对于寻求简单明了工具的人，并不是一个好产品！.

GNATS

GNATS 传统来讲，属于缺陷跟踪工具, 但根据Jeff Sutherland，已经支持 Scrum. 免费

Select Scope Manager

商业化产品，有试用版可下载。定制性比较差.

XP Plan-it

仅仅支持把你的数据放在他的server上，你通过下载的客户端更新和查看数据。。好像对大多数人来讲意义不大

XPWeb

另一个基于web的分布式方案。免费！

使用PHP+MySql可运行于Linux, Windows, or Mac.但其演示在IE7下工作不怎么样，没法详细测试.

XPlanner

最牛的祖父级的开源工具，完全免费，业界使用率排名第四，真的是穷人的项目管理工具！

作为一个基于Web的XP团队计划和跟踪工具，要求 Apace Tomcat。

XP 独特的开发概念如iteration、user stories等，XPlanner都提供了相对应的的管理工具，XPlanner支持XP开发流程，并解决利用XP思想来开发项目所碰到的问题。 XPlanner特点包括：简单的模型规划，虚拟笔记卡(Virtual note cards),iterations、user stories与工作记录的追踪，未完成stories将自动迭代，工作时间追踪，生成团队效率，个人工时报表，SOAP界面支持。.

ScrumWorks

个人认为对Scrum个方面支持最好的商业产品，市场排名第三位,我们一直在用。可支持不同的Team工作于不同的项目上，非常灵活。既有简单的web客户端，也有强大的java客户端。

有免费使用版，且无时间限制，我用的就是。

支持对Bugzilla和Jira的集成，带有主题过滤功能的burndown图表，以及其他辅助了解项目状况和走势的功能，还有众多别的特性。

ScrumWorks Pro与Bugzilla和Jira的集成，体现在它可以导入两者中的条目作为backlog条目，并且可以像对其他backlog条目一样，对这些条目进行操作。可以使用搜索来选择感兴趣的条目，并进行单独或多项导入操作。Infoq与Danube科技的JD Aspinall进行了交流，讨论了这个特性的本质，以及如何与ScrumWorks Pro一起使用Bugzilla和Jira。

我想提出这个特性请求的用户们都希望同时使用这两个工具。

产品的许多用户将他们全部的bug作为Product Backlog条目录入到ScrumWorks Pro中并进行跟踪。不过也有很多其他用户，由于其他种种原因，使用不同的工具来跟踪问题，并且只选择导入某些特定的缺陷到ScrumWorks Pro中。

Burndown图表现在可以按照主题进行分组。将backlog按照主题进行组织后（类似于web 2.0中使用标签），你可以高亮或是过滤这些backlog，并且能够使用同样的主题针对burndown图进行过滤。

ProjectCards

ProjectCards 维持项目管理的索引卡片，精确的具体内容，一个项目控制盘，搜寻和过滤能力和拖放反复计划。六十日免费的试用。

基于 Client/Server结构，支持plug-in for Eclipse.

TargetProcess

是一个敏捷项目管理与Bug跟踪系统。企业版提供很多定制的功能，包括Pre-paid 20 hours of development by TargetProcess stuff和提供开发指南与API参考的全部源代码。

这个工具挺适合小项目团队的。

这儿有个 Demo 帮助读者理解这个产品，内容是通过创建一个新的项目，在迭代计划时给开发人员指派故事（Story）。

他们的价格模式包括“按站点 / On Site”（需要安装）和“按需 / On Demand”（Web版），并提供折扣。

ExtremePlanner

一个基于web的工具，它的功能几乎与ProjectCards完全一样，但是它添加了在任务级别进行评估的功能，这一改进非常棒。由于是基于web的，所以它的界面可能不够漂亮，但是由于基于浏览器，它获得了一些灵活性（例如，当项目成员想在线查看状态报告时，如果是使用ExtremePlanner，就无需安装任何东西。）

我还在进一步考察这个工具，但是它看起来相当不错。

要求Windows, Linux, or MacOSX平台 (with Java 1.4.2 or higher and Apache Tomcat 4.1 or higher)

Rally

商业软件用户使用率排名第二位！支持用户需求的筛选、扩展的筛选标准、改进版本剩余时间表、新的通知规则（notification rules），以及用于Eclipse和CruiseControl.NET的连接器。

有免费在线试用体验版本.

Mingle

Mingle在ThoughtWorks官方站点可以免费下载，且5个用户以下的可以永久免费使用。Mingle是用纯Ruby打造的且运行在JRuby上的一个产品，由于ruby是一门脚本语言，所以其移植性就很好，用其编写的程序安装起来也甚是容易，在Windows、Mac和Unix多种主流平台上跑都是没有问题的；但也正是由于采用ruby编写，Mingle对硬件的要求也甚高，在我这台512M内存的机器上跑是超慢的、让人闹心的，建议还是放到性能好的、单独的服务器上，内存容量官方建议是2G。还遇到了好几次ie错误，只好放弃了。

Mingle后台存储采用数据库方式，目前仅支持mysql和Postgres两种数据库版本，这个比较遗憾，我无法使用现成的Oracle数据库了。

简单用了一下，发现如下很好的Features：

支持建立"个性化"项目模板，便于复用；
附带项目wiki，便于"项目知识积累和管理"；
丰富的card properties，使需求驱动的管理流程更加清晰；
支持card和源代码之间的link；.

TRICHORD

这个名为“TRICHORD”的敏捷项目管理工具，是基于精益思想的，对Scrum也适用。TRI指的是三种视角（时间、任务和团队），CHORD则是和谐的意思。

它作为全团队分享项目状态的一个工作空间来运作，里面提供三种层次的看板图——特性看板（发布—特性）、故事看板（故事—迭代）和任务看板（工作日—任务）。特性看板用停车场图来归纳，故事和任务看板用延烧图来归纳。

更多技术资源文章，讲座 ,培训，咨询请访问www.uml.org.cn

网站：UML软件工程组织

级	CMM		CMMI		类别
级	过程域	缩写	过程域	缩写	类别
5	技术更新管理	TCM	组织革新与部署	OID	过程管理
	过程更改管理	PCM	组织革新与部署	CAR	过程管理
	缺陷预防	DP	原因分析与决策	?	支持
4	软件质量管理	SQM	组织过程性能	OPP	过程管理
4	定量过程管理	QPM	定量项目管理	QPM	项目管理
3	软件产品工程同行评审	SPE PR	需求制定	RD	工程
			技术方案	TS	工程
			产品集成	PI	工程
			验证	VER	工程
			确认	VAL	工程
	组织过程聚焦	OPF	组织过程聚焦	OPF	过程管理
	组织过程定义	OPD	组织过程定义	OPD	过程管理
	培训大纲	TP	组织培训	OT	过程管理
	集成软件管理	ISM	集成项目管理	IPM	项目管理
	组间协调	ISM	集成项目管理	IPM	项目管理
	?		风险管理	RSKM	项目管理
	?		决策分析与决定	DAR	支持
	?		集成供应商管理	ISM	项目管理
	?		组织集成环境	OEI	支持
	?	IC	集成组队	IT	项目管理
2	需求管理	RM	需求管理	RM	?
	软件项目策划	SPP	项目策划	PP	项目管理
	软件项目监督与控制	SPTO	项目监督与控制	PMC	项目管理
	软件分包管理	SAM	供应协议管理	SAM	项目管理
	软件质量保证	SQA	过程与产品质量保证	PPQA	支持
	软件配置管理	SCM	配置管理	CM	支持
	?		度量与分析	MA	支持
1	?

评估类型	ISO15504兼容	SCAMPI 使用	主任评估师需求	评估组规模
Class A	×	可能	×	5-17
Class B	-	部分	-	2-7
Class C	-	部分	-	2-3

Xiangqun Financial Intelligent Algorithmic Cloud Developer向群财经智能算法交易与云计算开发http://sfebbf.xqact.com

2012年4月21日星期六