这份文档主要给出了一些常用的 TWiki 文章编辑方法。TWiki 是一个广泛使用的开源 wiki 系统，通常被企业和组织用户用来共享知识等。更多介绍请看它的官方站点：http://twiki.org 。

这只是作者的一份编程笔记，其实与网上早期版本的 TWiki 文档中文翻译有些重复，需要更多内容请查看参考文章和链接。

目录

1. 基本语法
1.1 话题
1.2 标题和段落
1.3 字体
1.4 列表
1.4.1 无序号列表
1.4.2 带序号列表
1.5 表格
1.6 链接
1.6.1 词条链接
1.6.2 外部链接
1.6.3 页面内锚点
1.6.4 图片和附件链接
1.7
图标
2. 页面编辑技巧
3. 参考文章和链接

1. 基本语法

[1.1 话题]

Wiki 的精神就是用词条描述世界，所以 TWiki 也是这样，它内部对内容的管理是用一个一个 WikiWord 来分类的。WikiWord 就是像前面这种两个单词构成的连接在一起的词组，里面大小写交错。

TWiki 的话题（topic）推荐用 WikiWord 来建立，如果用户输入的新话题不是一个 WikiWord，那么建立新话题的按钮就不会被激活。但是 TWiki 允许用户使用非 WikiWord 建立词条，需要手动勾选上允许使用非 WikiWord 建立话题。

[1.2 标题和段落]

1.2.1 标题
TWiki 中可以使用分级标题，分级标题的语法如下：
---+
---++
即在行首三个"-"和一个"+"代表一级标题，三个"-"和两个"+"代表二级标题，以此类推。当用户使用规范的标题记号建立好话题之后，可以很方便地使 用"%TOC%"标记建立一个标题目录。如果用户不想某个标题被包含，只需要在标记标记后加上两个感叹号"!!"，比如：

---+!! 目录
%TOC%
这样目录这个标题就不会包含在自动建立的目录里。

1.2.2 段落
TWiki 的段落分隔和 LaTeX 有点儿类似，段落之间需要空一行。如果想输入不被 TWiki 格式化的原始文字（比如源程序等），需要用标签将这些段落包起来，主要有以下两种标签：
<verbatim></verbatim>
<pre></pre>

区别是 <verbatim></verbatim> 中间的代码以完全原始方式显示，<pre></pre> 中某些 HTML 标签依然起作用。

[1.3 字体和分隔线]

1.3.1 字体
TWiki 使用字体的方式比较像 HTML 的标签，就是在字符串两头加上某些标记。比如：
*Bold Font* 粗体
_Italic Font_ 斜体
__Bold Italic__ 粗斜体
=Fixed Font= 等宽字符
==Bold Fixed Font== 等宽粗体字符
最最需要注意的一点是：这些标记"*_="必须内侧与文字相连，外侧为空格，标记之间也不得有空格。

1.3.2 分割线
TWiki 的分割线是在行首输入连续的多于三个的减号"-"，例如
----

[1.4 列表]

1.4.1 无序号列表
无序号列表的格式是：
*
*
即三个空格加"*"所进一层，六个空格加"*"缩进第二层，以此类推。

1.4.2 带序号列表
带序号列表的格式是：
1.
1.
即三个空格加"1"所进一层，六个空格加"1"缩进第二层，以此类推。注意，这里的"1"代表用阿拉伯数字编号列表，其它编号方式有"A"或"a"大小写 字母标号，"I"或"i"大小写罗马字母编号。

注意:这里后面的小数点可要可不要，可以一直使用"1"编号，也可用"1,2,3"递增编号，效果无区别。

[1.5 表格]

表格的建立是用竖线"|"分隔，比如：
|T1|T2|T3|
|A1|A2|A3|
就建立了一个两行三列的列表。单元格内部的左右对齐是利用和竖线的距离实现的。

[1.6 链接]

1.6.1 词条链接
如果是规范的多词 WikiWord 话题，可以使用双方括号直接括起来，例如：[[my wiki topic]]就会直接引用 MyWikiTopic 词条；如果是非规范话题，或者引用说明和引用话题不一样，需要使用引用与说明分开的格式，例如：[[MyWikiTopic][my WIKI topic]]。

1.6.2 外部链接
外部链接可以直接使用类似与词条链接的方式来引用，例如：[[
http://blog.solrex.org][Solrex 的博客]] 。

1.6.3 页面内锚点
在页面内可以定义锚点，这样可以使用链接在页面内跳来跳去。定义锚点的方法是在行首使用 #WikiWord，例如：
#FootNote Footnote is....
就定义了一个到该段的锚点。引用锚点和词条链接的方式也类似，例如：[[#FootNote][to footnote]]。如果引用别的页面的锚点，只需要在锚点前面加上该页面的话题名，例如：[[MyWikiTopic#FootNote][to another footnote]]。

1.6.4 图片和附件链接
如果引用在同一页面的附件或者图片（其实一般图片也是附件），链接的格式为：%ATTACHURL%/filename.extesion，比 如：%ATTACHURL%/about.pdf；引用在不同页面的链接，需要在文件名前面加上该页面主题的名字，比如：%PUBURL%/%WEB% /MyWikiTopic/about.pdf

[1.7 图标]

TWiki 预定义了很多图标，直接在文中就可以使用，比如帮助的小 i 图标是：%H%，update 的图标是：%U%，new 的图标是：%N%。合理使用这些图标能增强文章的可读性。

2. 页面编辑技巧

[1] 建立话题时合理分级，有规律地规划父话题和子话题关系。
[2] 处理重复话题时使用 %INCLUDE{"XXX"}% 来包含已有的话题，比如我已经有了 PersonalComputer 话题，在建立 PC 话题时候，就应该直接在页面中使用 %INCLUDE{"PersonalComputer"}% 来避免冗余。
[3] 使用%TOC%自动创建目录：当编辑一篇比较长的文章时，建议使用标题标记建立分级标题，最后使用 %TOC% 在上方建立一个可索引目录。

[4] 合理使用字体和图标增加可读性。
[5] 合理使用 HTML 代码来加强页面排版功能。TWiki 可以直接支持 HTML 代码，为了格式的统一，一般不建议直接使用 HTML。但有些页面排版过于复杂，使用 HTML 可以直接达到要求。
[6] 使用注释的技巧：TWiki 没有装 footnote 插件时候是不支持注释链接的，但是可以通过一些技巧来实现。我们可以先在注释或者引用列表前建立一个锚点：
#FootNote

---+ Footnotes
1 aaa
1 bbb
当文中内容需要注释时，使用 HTML 和 TWiki 链接一起加一个上脚标：aaa^{[[[#FootNote][1]]]}，这样 aaa 的右上角就可以出现一个方括号，里面是带到脚注链接的脚注编号 "1"。

3. 参考文章和链接

[1] 早期版本 TWiki 语法格式的中文翻译:
http://www.stlchina.org/twiki/bin/view.pl/TWiki/TextFormattingRules
[2] TWiki 官方语法文档：

http://twiki.org/cgi-bin/view/TWiki/TextFormattingRules

WBS具有4个主要用途：

WBS是一个描述思路的规划和设计工具。它帮助项目经理和项目团队确定和有效地管理项目的工作。 
WBS是一个清晰地表示各项目工作之间的相互联系的结构设计工具。 
WBS是一个展现项目全貌，详细说明为完成项目所必须完成的各项工作的计划工具。 
WBS定义了里程碑事件，可以向高级管理层和客户报告项目完成情况，作为项目状况的报告工具。 
WBS 是面向项目可交付成果的成组的项目元素，这些元素定义和组织该项目的总的工作范围，未在WBS中包括的工作就不属于该项目的范围。WBS每下降一层就代表 对项目工作更加详细的定义和描述。项目可交付成果之所以应在项目范围定义过程中进一步被分解为WBS，是因为较好的工作分解可以：

防止遗漏项目的可交付成果。 
帮助项目经理关注项目目标和澄清职责。 
建立可视化的项目可交付成果，以便估算工作量和分配工作。 
帮助改进时间、成本和资源估计的准确度。 
帮助项目团队的建立和获得项目人员的承诺。 
为绩效测量和项目控制定义一个基准。 
辅助沟通清晰的工作责任。 
为其他项目计划的制定建立框架。 
帮助分析项目的最初风险。 
WBS的最低层次的项目可交付成果称为工作包(WorkPackage)，具有以下特点：

工作包可以分配给另一位项目经理进行计划和执行。 
工作包可以通过子项目的方式进一步分解为子项目的WBS。 
工作包可以在制定项目进度计划时，进一步分解为活动。 
工作包可以由惟一的一个部门或承包商负责。用于在组织之外分包时，称为委托包(CommitmentPackage)。 
工作包的定义应考虑80小时法则(80-HourRule)或两周法则(Two Week Rule)，即任何工作包的完成时间应当不超过80小时。在每个80小时或少于80小时结束时，只报告该工作包是否完成。通过这种定期检查的方法，可以控制项目的变化。 
1. 创建WBS的方法

创建WBS是指将复杂的项目分解为一系列明确定义的项目工作并作为随后计划活动的指导文档。创建WBS的方法主要有以下几种：

使用指导方针。一些像美国国防部(DOD)的组织，提供MIL-STD之类的指导方针用于创建项目的WBS。 
类比方法。参考类似项目的WBS创建新项目的WBS。 
自上而下的方法。从项目的目标开始，逐级分解项目工作，直到参与者满意地认为项目工作已经充分地得到定义。该方法由于可以将项目工作定义在适当的细节水平，对于项目工期、成本和资源需求的估计可以比较准确。 
自下而上的方法。从详细的任务开始，将识别和认可的项目任务逐级归类到上一层次，直到达到项目的目标。这种方法存在的主要风险是可能不能 完全地识别出所有任务或者识别出的任务过于粗略或过于琐碎。 
2．创建WBS的基本要求

创建WBS时需要满足以下几点基本要求：

某项任务应该在WBS中的一个地方且只应该在WBS中的一个地方出现。 
WBS中某项任务的内容是其下所有WBS项的总和。 
一个WBS项只能由一个人责任，即使许多人都可能在其上工作，也只能由一个人负责，其他人只能是参与者。 
WBS必须与实际工作中的执行方式一致。 
应让项目团队成员积极参与创建WBS，以确保WBS的一致性。 
每个WBS项都必须文档化，以确保准确理解已包括和未包括的工作范围。 
WBS必须在根据范围说明书正常地维护项目工作内容的同时，也能适应无法避免的变更。 
3．WBS的表示方式

WBS可以由树形的层次结构图或者行首缩进的表格表示。

在实际应用中，表格形式的WBS应用比较普遍，特别是在项目管理软件中。

4．WBS的分解方式

WBS的分解可以采用多种方式进行，包括：

按产品的物理结构分解。 
按产品或项目的功能分解。 
按照实施过程分解。 
按照项目的地域分布分解。 
按照项目的各个目标分解。 
按部门分解。 
按职能分解。 
5．创建WBS的过程

创建WBS的过程非常重要，因为在项目分解过程中，项目经理、项目成员和所有参与项目的职能经理都必须考虑该项目的所有方面。制定WBS的过程是：

得到范围说明书(ScopeStatement)或工作说明书(StatementofWok，承包子项目时)。 
召集有关人员，集体讨论所有主要项目工作，确定项目工作分解的方式。 
分解项目工作。如果有现成的模板，应该尽量利用。 
画出WBS的层次结构图。WBS较高层次上的一些工作可以定义为子项目或子生命周期阶段。 
将主要项目可交付成果细分为更小的、易于管理的组分或工作包。工作包必须详细到可以对该工作包进行估算(成本和历时)、安排进度、做出预 算、分配负责人员或组织单位。 
验证上述分解的正确性。如果发现较低层次的项没有必要，则修改组成成分。 
如果有必要，建立一个编号系统。 
随着其他计划活动的进行，不断地对WBS更新或修正，直到覆盖所有工作。 
检验WBS是否定义完全、项目的所有任务是否都被完全分解可以参考以下标准：

每个任务的状态和完成情况是可以量化的。 
明确定义了每个任务的开始和结束。 
每个任务都有一个可交付成果。 
工期易于估算且在可接受期限内。 
容易估算成本。 
各项任务是独立的。 
6．WBS的使用

对WBS需要建立WBS词典(WBSDictionary)来描述各个工作部分。WBS词典通常包括工作包描．述、进度日期、成本预算和人员分配等信息。对于每个工作包，应尽可能地包括有关工作包的必要的、尽量多的信息。

当WBS与OBS综合使用时，要建立账目编码(Code ofAccount)。账目编码是用于惟一确定项目工作分解结构每一个单元的编码系统。成本和资源被分配到这一编码结构中。

7．WBS的实践经验

最多使用20个层次，多于20层是过度的。对于一些较小的项目4－6层一般就足够了。

　　当我们的办公室内堆满了杂乱无章的文件时，恐怕无法知道对于我们真正有用的文件在哪里，当我们的软件相目中收集了各种需求、意见、问题时，我们 也很难从中估算出整个项目的规模、工作量以及成本。因此，在估算之前我们首先要对众多信息进行整理、归类分析，从而得到一个条理清晰的项目计划，在这个计 划提供的框架内，才可能开始正确的估算。精心的规划是任何一个软件开发项目成功与否的关键，有了规划就有如成竹在胸，之后无论风云变幻，都有应对入流的方 法。当然只有正确的规划，才能给软件开发指引正确的方向。

　　软件项目规划的重点是对人员角色、任务进度、经费、设备资源、工作成果等等做出合适的安排，制定出一些计划(包括高层的和细节的)，使大家按照计划行事，最终顺利地达到预定的目标。blog.mypm.net

　　1.1、规划的第一步：确定软件范围

　　确定软件范围，就是确定目标软件的数据和控制、功能、性能、约束、接口以及可靠性。这项工作和需求分析是很类似的，如果之前已经达成需求分析规 约，那么可以直接从《需求分析说明书》中把有用的部分拿来使用。如果还没有开始需求分析，关于确定软件范围的方法方面，我们可以采用许多需求分析技术(如 需求诱导)，从客户那里得到一个具体的软件范围。当然如果是一次全新的软件边界探索，就应当考虑软件本身可行性问题，包括团队是否具备在技术、财务、时 间、资源上游可靠的保障，软件本身在市场上是否有可靠的竞争优势 ，等等。

　　获得软件范围，最直接最可靠的来源就是用户对软件的需求描述。例如，在开发一个C/S架构的铁路供电段数据上报系统中，客户向我们提供了以下的目标软件需求描述：

　　在供电站总部每天结束前要审核下属节点操作员(30~40个)的供电安全数据报表，要求每个节点必须在下午5：30~6：00之间上传数据。总 部系统通过自动分析，整理出整个区内的安全形势报表，并自动反馈到每个节点。各个节点之间通过调制解调器拨号(MODEM)用内部电话线相连，每个节点电 脑主机配备一个MODEM。上传数据为制式报表出了制式信息外，系统自动附加操作员姓名、上报时间、上报节点名称。信息一旦上传，节点端就不可以对已提交 信息进行修改、删除，只能阅读、查询。节点间数据互相隔离，只有总部才具备对各个节点数据的管理权限，但是对于归档数据(一旦审核完毕的数据，就进行归 档)总部不具备删改的权限。系统设置数据库管理员，独立于审核权限，其职责是对历史数据的清理维护。项目经理圈子

　　通过上面的描述，我们通过提炼和简化，得到软件的一下功能：

　　◆ 节点数据录入、查询、上传

　　◆ 总部数据汇总、查询、反馈

　　◆ 总部与节点的互联

　　◆ 总部数据库存储

　　◆ 节点数据的本地存储项目管理者联盟文章

　　1.2、规划的第二步：确定工作所需资源

　　软件工作所需资源包括：工作环境(软硬件环境、办公室环境)、可复用软件资源(构件、中间件)、人力资源(包括不同各种角色的人员：分析师、设 计师、测试师、程序员、项目经理……)。这三种资源的组成比例，可以看作一个金字塔的模式，最上面是人力资源、其次是可复用软件资源、最下面是工作环境。 最上面的是组成比例最小的，最下面的是组成比例最大的部分。

　　■ 人力资源

　　一个项目到底需要多少种职务的人员构成、多少数量的人员总量，再能成为最有创造力的团队呢?这恐怕是最让项目经理头疼的事情了。任何一个软件工 程，都必须在确定软件的工作量之后，才能清楚地知道究竟需要多少人力才能以最小成本和最高效率完成任务。在这之前，不能盲目地进行人力扩充，而且绝对不能 为了给公司抬高门面，盲目招收高学历。

　　■ 可复用软件资源

　　这是一个容易在计划阶段被忽视的重要资源，很多人总是进入编码阶段才发现可复用资源的价值和存在。经过长期的项目积累或是购买，公司的软件资源 库中或许已经积累了大量的可复用资源，但在当前任务中，只能选择有价值的资源。根据不同的应用、时间、来源，可复用软件资源被分为以下几种：

　　可直接使用的构件：已有的，能够从第三方厂商获得或已经在以前的项目中开发过的软件。这些构件已经经过验证及确认且可以直接用在当前的项目中。

　　具有完全经验的构件：已有的为以前类似于当前要开发的项目建立的规约、设计、代码、或测试数据。当前软件项目组的成员在这些构件所代表的应用领域中具有丰富的经验。因此，对于这类构件进行所需的修改其风险相对较小。

　　具有部分经验的构件：已有的为以前与当前要开发的项目相关的项目建立的规约、设计、代码、或测试数据，但需做实质上的修改。当前软件项目组的成员在这些构件所代表的应用领域中仅有有限的经验，因此，对于这类构件进行所需的修改会有相当程度的风险。

　　新构件：软件项目组为满足当前项目的特定需要而必须专门开发的软件构件。training.mypm.net

　　在采用构件的时候，应当以低成本、低风险为使用前提。如果任何一个漂亮的构件的应用，可能会带来潜在出错的风险或者必须经过复杂修改或者效率低 下时，我们都应当毫不犹豫地把它抛弃。我们只采用那些能够满足项目的需要且可直接使用的构件，或者具有完全经验的构件，或者经过稍微修改便可使用的构件。

　　■ 环境资源

　　“工欲善其事，必先利其器”，要得到高效的开发过程，就必须向工作人员提供良好的软硬件环境，包括开发工具、开发设备、工作环境、管理制度。一般管理人员都会购买可以满足需要的软件开发工具和硬件平台，但是工作环境和管理制度往往被忽视。

　　站在人件的角度看，向工作人员提供更轻松自在、安静舒适的办公环境的公司员工往往比整天在狭小隔间中工作的公司员工，产生更高的工作效率。而那 些拥有灵活人性化的管理制度的公司，比整天加班的公司更能留住高技术的人才。所以如何在有限资金中，规划一个合理的环境是很重要的事情。

到此为止，估算前的项目计划已经完成，我们已经形成一个工程开发框架。这是一个有界限的框架，虽然还不够精确，但足以进行估算的工作。

　　2、估算的对象

　　目前为止，一个较为准确的软件项目估算的定义是：在给定公差范围内，对于姚开发的软件规模的预测，以及对开发软件所需的工作量、成本和日历事件的预测。这个概念指出了一个事实，即估算是一种大约的估计，是将误差限定在一定范围内的估计。

　　估算主要包括以下几个重要内容：项目管理者联盟

　　◆ 规模估算

　　软件估算首先要将整个工程的规模估算出来，才能进行下面的其他估算。规模，就是一个工程可量化的结果，是用具体数字来体现项目的描述。规模估算的信息来源是清晰、有界限的用户需求。

　　◆ 工作量估算

　　这是对开发软件所需的工作时间的估算，它和进度估算一起决定了开发团队的规模和构建。通常以人时、人天、人月、人年的单位来衡量，这些不同单位之间可以进行合理的转换。blog.mypm.net

　　◆ 进度估算

　　进度时项目自始至终之间的一个时间段。进度以不同阶段的里程碑作为标志。进度估算是针对以阶段为单位的估算，而不是对每一个细小任务都加以估算，对任务的适当分解很重要，分解得越细反而会不准确。因为任何一个软件工程，在各个方面都有与生俱来的不确定性。

　　◆ 成本估算

　　包括人力、物质、有形的、无形的支出成本估算，其中以人力成本为主要部分。比较容易被忽视的使学习成本、软件培训成本、人员变动风险成本、开发延期成本等，一些潜在成本消耗。转自项目管理者联盟

　　3、估算的策略

　　在软件估算的众多方法中，存在着“自顶向下”和“自底向上”两种不同的策略，两种策略的出发点不同，适应于不同的场合使用。项目管理培训

　　当然由于这完全是从客户要求出发的策略，而由于软件工程是一个综合项目，几乎没有哪个项目能完全保质保量按照预定工期完工，那么这样一个策略就 缺少了许多客观性。但是由于这样完成的估算比较容易被客户、甚至被项目经理所接受，在许多公司我们看到这样一个并不科学的策略仍然被坚定地执行着。

　　3.2、自底向上的策略

　　与自顶向下的策略完全相反，自底向上的策略是一种从技术、人性的角度出发看问题的策略。在这样一个策略指引下，将项目充分讨论得到一个合理的任 务分解。在将每个任务的难易程度，每个任务依照项目成员的特点、兴趣特长进行分配，并要求进行估算。最后将估算加起来就是项目的估算值。

　　显然自底向上的这种策略具有较为客观的特点，但是它的缺点就是这样一来项目工期就和客户的要求不一致了。而且由于其带来的不确定性，许多项目经理也不会采用这种方法。

　　4、估算的方法

　　显然估算是建立在客观实际上，对未来尽可能合理的一种预测。那么估算本身的不确定性，决定了它不可能是百分之百准确无误的。在项目刚开始时，人 们对产品需求、技术、市场预期、人员素质等因素的了解还远远不够，在这种情况下人们很难作出准确的估计。但是依据某种方法进行估计显然比瞎猜好得多。

　　估算方法有很多，大致分为基于分解的技术和基于经验模型两大类。基于分解的技术的方法包括功能点估算法、LOC估算法、MARK II等;基于经验模型的方法包括IBM模型、普特南模型、COCOMO模型等。

　　4.1、FP功能点估算法

　　功能点估算法是一种在需求分析阶段基于系统功能的一种规模估计方法。通过研究初始应用需求来确定各种输入、输出、计算和数据库需求的数量和特 性。这种方法的计算公式是：功能点=信息处理规模x技术复杂度。信息处理规模包括各种输入、输出、查询、内部逻辑文件数、外部接口文件数等等;技术复杂度 包括性能复杂度、配置项目复杂度、数据通信复杂度、分布式处理复杂度、在线更新复杂度等等。

　　4.2、LOC估算法

　　这是一种从技术的角度来估算的方法总称，其中又包含许多方法。这类方法以代码(LOC)作为软件工作量的估算单位，在早期的系统开发中较为广泛 使用。基于LOC的估算，又有点也有缺点。优点在于方便计算、容易监控、能反映程序员的思维能力;缺点在于代码行数的含糊不清，不能正确反映一项工作的难 易程度以及代码的效率。因此在传统的LOC方法进行了许多改进。其中不断被使用，且不断演化的方法包括以下：www.mypm.net

　　PERT功能点估算法：PERT对各个项目活动的完成时间按三种不同情况估计：一个产品的期望规模，一个最低可能估计，一个最高可能估计。用这三个估计用来得到一个产品期望规模和标准偏差的Pert 统计估计，Pert 估计可得到代码行的期望值和标准偏差SD。

　　类比估算法：类比法适合评估一些与历史项目在应用领域、环境和复杂度的相似的项目，通过新项目与历史项目的比较得到规模估计。类比法估计结果的 精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。项目管理者联盟

　　Delphi估算法：Delphi法是一种专家评估技术，在没有历史数据的情况下，这种方式适用于评定过去与将来，新技术与特定程序之间的差别。对于需要预测和深度分析的领域，依赖于专家的技术指导，可以获得较为客观的估算。通过专家们的互相讨论，还可以博取众长。

系统分解：将系统分成若干个易于用LOC估算的部分，将其各个估算结果累加就是LOC的总规模。其中关键是建立起SBS(系统分解结构)，它描述了 系统的不同组件。SBS还被使用在其他重要的地方，如系统设计、系统分析等。在进行分解的时候，可以采用自由讨论的形式，可以获得更合理的SBS构成。

　　4.3、IBM模型估算法

　　该模型是Watson和Felix在1977年发布的，是基于IBM联合系统分布负责的60个项目的总结而得到的模型。该模型是一个静态模型，而参考数据只有60多个项目，因此有很大的局限性。项目经理圈子

　　4.4、COCOMO估算法

　　Boehm在其经典著作“软件工程经济学”(software engineering conomics)中，介绍了一种软件估算模型的层次体系， 称为COCOMO(构造性成本模型，COnstructive COst MOdel)，它代表了软件估算的一个综合经验模型。

　　COCOMO 模型是适用于三种类型的软件项目：(1)组织模式——较小的、简单的软件项目，有良好应用经验的小型项目组，针对一组不是很严格的需求开展工作(如，为一 个热传输系统开发的热分析程序);(2)半分离模式——一个中等的软件项目(在规模和复杂性上)，具有不同经验水平的项目组必须满足严格的及不严格的需求 (如，一个事务处理系统，对于终端硬件和数据库软件有确定需求);(3)嵌入模式——必须在一组严格的硬件、软件及操作约束下开发的软件项目(如，飞机的 航空控制系统)。项目管理培训

　　4.5、软件方程式估算法

　　软件方程式是一个多变量模型，它假设在软件开发项目的整个生命周期中的一个特定的工作量分布。该模型是从4000 多个当代的软件项目中收集的生产率数据中导出的公式。初期的方程式较为复杂，通过，Putnam 和Myers的努力又提出一组简化的方程式。当然这种方法也是基于长期的参考数据的积累而得到的。

　　4.6、WBS估算法

　　这是一种基于WBS(工作任务分解)的方法，即先把项目任务进行合理的细分，分到可以确认的程度，如某种材料，某种设备，某一活动单元等。然后估算每个WBS要素的费用。采用这一方法的前提条件或先决步骤是：

　　对项目需求作出一个完整的限定。blog.mypm.net

　　制定完成任务所必需的逻辑步骤。

　　编制WBS表。

　　项目需求的完整限定应包括工作报告书、规格书以及总进度表。工作报告书是指实施项目所需的各项工作的叙述性说明，它应确认必须达到的目标。如果 有资金等限制，该信息也应包括在内。规格书是对工时、设备以及材料标价的根据。它应该能使项目人员和用户了解工时、设备以及材料估价的依据。总进度表应明 确项目实施的主要阶段和分界点，其中应包括长期定货、原型试验、设计评审会议以及其他任何关键的决策点。如果可能，用来指导成本估算的总进度表应含有项目 开始和结束的日历时间。

　　除了以上介绍的几种方法外，还有一些其他的方法：类比估算、推测估算、Standard-component估算法、普特南估算法等。当然不同 的方法适用于不同的具体环境，有些方法虽然很好但并不一定适合当前的任务。只有量体裁衣，具体问题具体分析，才能得到尽量合理的估算。

5、估算的戒律

　　记住：应该满足于事物的本性所能容许的精确度，当只能近似于真理时，不要去寻求绝对的准确?? ——亚里斯多德

　　对于任何一个项目经理，都知道要慎重估算，但是我们仍然会看到人力资源的浪费和财力资源的匮乏，在许多项目中存在。对于宝贵的资源，我们不是用得太多，就是根本不够用。因此，有以下前人总结出来的一些经验以供借鉴。项目经理圈子

　　不要追求完美：就像没有人能预测出未来，如果还没有完成，就不要企图完美的结果。更何况估算的太精确，反而会失去灵活机动的空间。

　　不要为满足预算而估算：如果这个项目的预算根本不能完成100%的任务，那么就不要让你的团队委曲求全。正确地反映客观现状，不仅可以争取应得的权利，而且是完成任务的前提。

　　不要随意削减估算结果：有很多老板喜欢把项目经理递交的估算，不假思索地砍掉一部分。这是一种不负责任的做法，如果要削减一定要有理由。项目管理培训

　　客观地估算，不贪多不偷减：就像老板不能随便削减你的估算一样，你也同样不能在估算的时候，贪多或是偷减。贪多必然导致会浪费，偷减必然导致不足。这两个结果恐怕都不是一个合格的项目经理的作为。

　　客观利用过去的经验：对于以往估算的经验，当然是宝贵的财富，但是如果财富用错了地方就会变成垃圾。在使用经验时，要注意现在和参考经验之间的差异。不要忘记，随着时间的推移，计算机领域技术的更新，许多观念都在发生着改变。

　　不要以客户目标作为估算的结果：客户是上帝，软件公司一定要尽力实现客户的需求。但我们要实现的是合理的目标，况且不能为了完成目标而去堆积数字，这样岂不是因果倒置了。

　　不要隐匿不确定的成本：软件开发中存在潜在风险，是很正常的事情。现在风险就会带来潜在的成本，如：突然一位程序员离职，导致工作进度路落后。我们不可能估算到任何一种可能发生的情况，但有责任把可能出现的一些关键环节列出来。

　　我国软件从业人员有50多万人，在6000多家软件企业中有60%是50人以下的小企业，1000人以上的企业仅10余家，软件出口额不到印度 的10%。在印度的优秀软件企业如Wipro、Infosys、Tata中，软件开发项目的按时完成率高达95%以上，可以说是项目管理能力促进了印度软 件企业承揽外包业务和规模化的发展。据统计，目前我国软件企业项目的按时完成率平均为20%左右。可见，我国软件企业在项目管理能力方面与印度软件企业相 比还存在很大差距。项目管理者联盟

　　一、面向利益相关者的项目策划

　　软件项目策划的目的主要在于明晰定义项目的价值和项目目标，它是软件项目正式启动的基础是明确项目需求的基础，也是控制项目范围的基础。据统 计，超过50%的软件项目都遭受过不充分的需求管理的问题，平均有25%的软件项目需求会发生变化。对有缺陷的需求、设计、代码进行返工的花费占整个项目 费用的40%—50%。项目策划的要点包含以下四个方面。training.mypm.net

　　1.识别和定义项目的利益相关者www.mypm.net

　　现代项目管理的核心理念是项目必须让其利益相关者满意，要理解和定义项目的价值，进而在此基础上定义项目的目标，必须从识别项目的利益相关者入 手。然而，实践表明，识别清楚软件项目的利益相关者并不是一件容易的事。有时一个项目进行了很长时间，但项目组未必知道项目的真正客户是谁，最常犯的错误 是仅将项目成果的使用者作为客户。例如，电子政务系统的真正用户是该机关的决策层，而不是具体负责这个电子政务项目的某个部门。如果需求仅仅来自负责这个 项目的某个部门，那么即使这个系统建好了，也极有可能没有真正达到目的。但是由于各种原因，决策层人员往往没有足够的精力来关心这件事，这时如果项目组不 去想方设法解决这个问题的话，那么，这个项目从一开始就埋下了“陷入泥潭”的阴影。此外，必须识别出具体的项目发起人并充分发挥其作用。实践过程中易犯的 错误是误将一个部门、一个机构作为项目的发起人，这样的结果是决策时有很多人，但真正需要项目发起人提供资源、予以协调时却找不到人。

　　2.促成利益相关者的参与

　　不仅是在策划活动中，在整个软件项目的生命周期内都必须强调项目利益相关者的参与，必须要与利益相关者一起启动项目。由于软件项目的成果将改变 人们的生活或工作方式。因此，客户必须在项目策划阶段就了解项目成果对其生活或工作方式的影响，他们必须开发相应的政策、流程等以准备接受项目成果。目前 众多的ERP项目之所以失败，重要的一个原因是人们误认为ERP项目仅是一个信息系统项目，该项目带来的仅仅是一个信息产品。其实，ERP项目带来的是一 新的运营方式，如果企业在没有做相应调整的情况下强行引入ERP，将会使企业运行的混乱速度加快而不是更好。事实表明，促使软件项目成功的最重要的要素莫 过于利益相关者的全过程参与。项目经理圈子

　　3.培育/运用行业专家项目经理圈子

　　软件项目的价值是为了实现某些商业目的，它们一般是由行业专家而不是由软件开发人员挖掘出来的。许多软件企业被投标价格所困扰，其原因有来自市 场竞争方面的，更多的则是软件企业没有能够挖掘项目的价值所致。目前，许多软件企业的弱点在于缺乏行业专家，它们没有意识到行业专家也是专业人员，而只是 将软件开发人员作为专业人员对待。在项目定义活动中，软件开发人员常犯的错误有三点：需求镀金、需求过滤和需求包办。所谓镀金，是指软件开发人员不顾客户 的实际需求，片面强调和夸大技术先进性;所谓需求过滤，是指软件开发人员根据自己的技术偏好对客户的需求进行了主观筛选;所谓需求包办，是指客户将需求分 析委托给“专业的”软件开发人员，而他们也乐得如此。实践证明，缺乏行业专家的项目策划所产生出来的东西一般是能力过剩的、不适用的，甚至是完全不能用 的。如果软件企业没有自己的行业专家，必须善于利用外部的行业专家。

　　4.不可忽视项目的验收标准

　　对项目目标一致性重视程度不够，是项目启动过程中普遍存在的一个问题。很多项目管理者低估了达成项目目标一致性的难度，在这方面投入的精力不 够，往往简单地认为目标已经达成一致。很多项目其实是在目标没有定义清楚的情况下匆忙启动的。因此，软件项目策划的结果必须使利益相关者对项目目标的理解 达成一致。要做到这一点，最有效的办法是设定项目的验收标准。可以以项目的客户为例说明这一点。客户的需求包含多个方面，其中既有对项目成果特性的要求， 又有客户在感情等方面的需求。简单说来，客户的需求可以分为三类：项目经理圈子

　　第一类是“Musts”，即如果缺少了就不能实现项目基本目的的成果特性;

　　二、基于统计数据的项目计划

　　软件项目计划过程面临的最大挑战就是计划的准确性差。据统计，在对软件项目进度与成本估算时，开发者的估算比现实要乐观，大约低20%到 30%;大多数项目实际完成时间超过估算进度的25%到100%，少数的进度估算精确度达到了10%，能控制在5%之内的项目十分罕见。要提高软件项目计 划的准确性，需要把握以下三点：项目管理培训

　　1.加强基础数据的统计与分析

　　软件项目都是具有独特性的，不能照搬其他项目的经验作为制定本项目计划的依据。因此，在企业范围内加强对项目基础数据的统计分析以得出规律是十 分必要的。项目管理既是科学又是艺术，由于文化的差异，西方发达国家强调的是管理中的科学性，而我国的绝大多数企业强调的是管理中的艺术性。由于不重视基 础数据的收集和统计，软件项目的计划常常是凭经验或“拍脑袋”而定的，企业并没有足够的统计数据来支持计划的制定。科学管理尽管是在上个世纪初，对制造业 和体力工人提出的，但其中提出的“不能度量就不能控制”的理念依然值得软件企业在管理项目时采纳。

　　2.以面向学习和改善系统的评价原则促进数据统计training.mypm.net

　　评价方式将决定人们的行为，要想改变人们的习惯，仅靠讲道理是难以见效的，还必须辅之以相应的评价体系。软件企业在项目管理评价进程的一个误区 是将评价的重点放在人的方面，而忽视了很多项目问题在于管理系统本身这个事实。据统计，人员的敬业精神和能力不够只占项目失败原因的10%左右，在大约 90%的原因来自于项目管理系统的架构与流程等方面。

　　3.谨防里程碑陷阱

　　众所周知，里程碑是项目计划与控制中的一个极为重要的概念，也正因为如此，人们也易于过于依赖里程碑，反而使项目计划落空。里程碑陷阱表现在以 下几个方面：首先，人们在软件项目的里程碑被设定以后，认为“目标管理是只问结果，不计过程”，从而忽视对过程的监控而导致项目里程碑不能按期达到。大多 数软件企业的从业人员属于知识工作者，他们对授权的要求较强烈，这方面的误区更易发生。第二，对里程碑控制不严。因为大部分里程碑毕竟只是一些项目的中间 结果，在项目过程中人们易于放松对里程碑变更的控制，易于出现里程碑大多按期完成而项目却难以按期完成的现象。项目活动彼此是有关联的，一个里程碑的延迟 会导致连锁反应，甚至可能导致项目工期的失控。第三，里程碑的设置仅仅由项目组根据项目本身的特点而定，忽视了与利益相关者的沟通并得到他们的承诺。

　　三、基于专业分工的项目资源动态调度

　　在软件项目失败的原因中，项目组织和人员的问题占到40%以上。因此，对项目资源的有效组织和调度是十分重要的。对于软件企业来说，最重要的资源莫过于人力资源，要在项目中充分组织和调度人力资源，需要做好以下两点：bbs.mypm.net

　　1. 实现人力资源的“分类分级”管理

　　由于没有对人力资源做到专业分工基础上的动态调度，大量企业的人力成本难以降低，项目组织运行的效果也难以保证。由于软件行业竞争的加剧，降低 项目成本成了当务之急，而降低项目所占用的人力资源成本更是重中之重。目前，许多软件企业对项目人力资源的使用可以用“5个人干3个人的活，拿5个人的 钱”来概括。要想改变这一点，做到“3个人干5个人的活，拿4个人的钱”这种理想状态，有效的办法是实现人力资源的“分类分级”管理。中创软件采取的“分 类分级”是指将企业员工划分为需求分析员、系统分析员、设计人员、编码人员、测试人员和QA等，并界定其不同的等级，能够做到可以测量出不同类型、不同层 次的人员的小时价格。这种价格是制定项目人力资源预算和成本控制的基础。目前，很多企业强调“复合型人才”，这容易产生一个误区。在许多软件企业的项目 中，有相当多的人既做设计又做编码还做测试，这不仅使项目的运行效率低、出错率高，也使项目的人力成本提高、人员还不满意。合理的方式是在专业分工、“分 类分级”的基础上，通过有效的项目团队组织机制将各类人员集成起来。

　　2.实现人力资源的动态调度

　　众所周知，有多种项目的组织方式。只有既能聚集于项目目标的实现，又能充分、有效调度企业资源的项目组织方式才是合理的。项目组织是一种临时性 的、动态的组织，由于它不应该有冗余人员，因此，资源调度的有效性基于资源调度的动态性，理想的状态是“需要的时候，需要的人能来;不需要的时候，不需要 的人能走”。企业能做到这一点，必须要有两个条件：人员已经“分类分级”，以及企业的各职能部门成为“资源库”。实践表明，“分类分级”和动态调度将能使 软件企业在项目实施过程中提高效率、降低人力资源的结构性成本和提高员工的整体满意度。www.mypm.net

四、基于可视化工具的项目监控

　　项目管理的指导思想在于不仅关注项目的成果，还要关注项目的过程。调查表明，在75%的软件企业处于开发流程的混乱状态，超过50%的软件企业 需要改进其配置管理，大约有60%的软件企业遭受着不同程度的质量保障体系的困扰。对项目过程控制的忽视，将导致项目范围的蔓延等项目风险的增加。要做好 对项目过程的有效监控，需要做好以下两点：项目管理者联盟文章

　　1.项目过程的监控要做到可视化blog.mypm.net

　　项目管理是一种典型的系统管理，也是一种典型的变化管理。项目过程控制的目标在于对项目成果(包括中间成果)的可预见、项目资源的可调度、项目 问题的可追溯、项目组绩效的可评价等几个方面。在一个软件项目中，有成百上千的相互关联的活动，一个活动在工期、资源和预算等方面的变化将对整个项目产生 连锁反应。项目管理的定律之一是“魔鬼藏在细节中”，项目经理和高层管理人员必须在对项目各种活动的变动全面了解的基础上，才能确定工作的焦点。同样，由 于项目组成员存在不同的分工，要使他们都能够明了各自的工作对项目的目标起到什么作用和影响，不能仅靠鼓励他们提高对项目的整体责任感，也不能仅靠评价机 制来驱动他们共同承担项目的责任，还必须使他们能够直观地看到他们的工作与项目目标之间的动态关系。即便是一个经验丰富的项目团队，如果不能完全理解项目 的每一个组成部分，不能形象、直观地了解项目的各部分之间的关联关系，也容易犯“一叶障目，不见泰山”的错误。只有将项目的运行做到可视化才能够帮助他们 解决这些问题。

　　2.要形成企业范围的数字神经系统项目管理者联盟文章

　　要做到项目过程控制的可视化，必须借助于项目管理的工具。有很多项目管理的方法和工具，如WBS、网络图、甘特图等方法以及Microsoft Project等工具有助于可视化。然而，这些方法和工具大多为单个项目服务的，要在整个企业范围内做到这一点，需要开发专门的可视化项目管理数据平台。bbs.mypm.net

　　五、着眼于提高企业项目管理整体能力的知识管理

　　与国际先进的软件企业相比，我国软件企业普遍不重视对知识的管理，企业项目的成功度过多地依赖于项目经理，项目管理的水准是项目经理的水准，而 不是企业的水准。软件企业属于知识型企业，其无形资产能够占到总资产的70%以上，管理无形资产的能力将成为软件企业的重要竞争力。企业的无形资产包括两 大部分：一部分是企业形象，另一部分是企业能力。软件企业形象的树立靠的是成功的案例(项目)，而企业能力包括属于企业的知识和属于员工的才干两方面。对 于企业能力的管理是要尽可能将员工的才干转化为企业的知识，并提高这种知识水平。只有这样才能提高软件企业的项目管理成熟度。要管理好企业的项目管理整体 能力需要做好以下两点：

　　1.建立和管理好项目事件库转自项目管理者联盟

　　由于信息技术的飞速发展，能否按期完工成了判断软件项目是否成功的极为重要的指标。控制项目工期有很多方法，其中最常用的是关键路线法 (CPM)。然而，决定软件项目工期能否近期完成的因素大多是那些事件(issue)，即需要被解决的障碍性问题。事件常常不是项目组成员能够独自解决 的，它们需要依靠整个企业的力量，甚至需要利用外部的专业资源。为了做到这一点，中创软件着力于软件项目事件库的建设。项目尽量有其独特性，但借鉴一个企 业内部，从同类型的项目之间的经验教训提炼出来的知识是十分有价值的。中创软件事件库管理的主要职能是把公司项目管理中的各种成功、失败的案例放在数字神 经系统中，相关人员遇到问题时，可随时在数字神经系统根据“关键字”进行查询，参考以前类似问题是如何处理，从而提供帮助。training.mypm.net

　　2.做好项目收尾的经验总结

　　与项目启动前的项目策划一样，项目的正式收尾是十分重要的。收尾的作用不仅对项目的利益相关者有一个正式的交代，还有一个重要职能是对项目整个 过程中的经验教训予以提炼，形成企业的知识财富。知识管理的目的是为了管理变化，没有足够的知识，企业就难以知道该如何应对项目中的变化。知识管理包括知 识的挖掘、整理和使用等内容。把知识挖掘出来，是一件非常艰苦的工件。企业的知识往往是隐含、散落在员工群体中，有时不是大家不想表达出来，而是可能并没 有意识到。因此，需要将员工的隐性知识转化为公司的显性知识。为了管理好知识，建立项目管理办公室，专门负责对项目管理相关文档进行分类、整理和统计，负 责适合本企业的项目管理工具、模板和方法的开发、研究及对员工运用的培训。

　　要提高软件企业项目管理的成熟度，企业需要付出艰苦的努力，在某种程度上要重塑企业文化。项目管理机制的推行必须从高层开始就坚定信念、全力以 赴、勇于实践，还必须要有足够的耐心才能获得理想的成效。项目管理是一个实践课题，有时候虽然说起来非常简单，但真正实施起来有大量具体问题要做。如果企 业不愿意真正地去投入、去认真地做的话，那么期望得到理想的项目管理成果只能是一句空话，是不可能成功的。转自项目管理者联盟

 九连所承担的是一个项目，连长谷子地就是一个项目经理。从项目流程的角度进行解剖，对这个项目的管理哪些是成功的，哪些又是失败的呢？

　　悲剧的主要环节在“项目控制”

 工作可划分为两大类：常规工作、非常规工作（即项目）。《集结号》中九连所承担的任务，是一个非常规工作，属于项目的范围，而连长谷子地自然就是一个典型的项目经理。这是一个什么项目呢？谷子地组织战士阻 击敌人。预期达成什么样的目标呢？掩护大部队撤退。从过程来看，这次阻击战是一次性的；从组织来看，这次任务是临时性的，任务结束于集结号声响；从条件来 看，这次任务仅仅为这次战役服务，具有变动性。当明确了谷子地的任务属于项目之后，我们从项目流程的角度来对该项目进行步步解剖。项目管理有哪几步流程 呢？前期——选择；中期——计划、执行、控制；后期——结束。

　　从项目选择来看，掩护大部队转移时派出兵力阻击敌人进攻，这是正确的。

　　问题出在计划上。作战时间和资源分 配值得商榷，区区47人的队伍，能否挡住具有优势兵力的敌人多次进攻？能否拒敌至少4小时？在计划时，恐怕连团长心里都打鼓。在选择项目经理人谷子地时， 在人这个资源上也是有问题的。如果作为连长的谷子地指挥素质高明的话，就不应在开头那段巷战中，6个尖兵遭伏击，就呼啦啦一片从正面冲上去，而是要正面佯 攻，侧翼绕过。谷子地在后面战斗中，并没有充分利用地利等因素进行智取巧打，而是一味拼命。从这点看，团长挑选谷子地的连队实施阻击，实则是个冒险，打硬 仗光靠勇字还不行。

　　执行不折不扣。虽然敌众我寡，困难重重，但战士们英勇作战，使阻击项目得到不折不扣的执行。就执行质量而言，虽然坚持12小时之久，可付出了全连阵亡的代价。

　　本项目的悲剧正是凝结在“控制”这个环节。项目控制的要素主要有范围、质量、时间、成本。团长策划这个项目时，基本上是不惜时间、不惜人力的， 导致这个项目的控制环节无法实施。一个鲁莽的团长，下了一个鲁莽的命令。由于通讯无法联络的缘故，作为项目经理的谷子地与阻击项目严重脱节，无法真正行使 项目经理的权力。虽然有战士企图假装听到集结号，试图挽救最后几名战士的生命，但终究不是项目经理，无法行使足够的权力去管理和协调项目工作。

　　根据战争常识，将军带兵外出打仗，有时难以与总部保持信息畅通，怎么办呢？一般就会再给出一个预备方案，指示将军随机应变。这样项目风险就会大大降低，至少不会全军覆没。

　　结果令人遗憾。项目管理一般应达到这样几个方面的满意，组织获益、客户满意、相关利益者满意、成员愉快、项目经理满意。就谷子地这个项目来看， 组织获益是部分达到了。但是，其他几方面，没有一方面满意。我们看到这个项目很难对烈士本身以及其家属交待，阻击战下来居然只有连长一个人活下来，作为项 目执行负责人，项目失败了，资源耗尽了，应该付相应责任。作为项目经理的谷子地，由于偶然的原因活下来，却怀着终生的愧疚。甚至那个最大的责任人，团长刘 泽水，最后也是由于同样的原因，做了同样失败的项目：在另一场阻击战中，电台被打坏，接不到上级的撤退命令，拼上了更多的战士的生命，自己也牺牲在战争 中。

　　《集结号》的悲剧恰恰是企业在项目进展中经常遇到的困惑。“1345”分析模型是否能够解决企业的这些难题？

　　少一点鲁莽多一点项目管理

项目兴，企业兴；项目衰，企业衰。一个企业发展离不开项目。在企业管理中，我们是有条件去学习项目管理知识的，但实施项目时，很多时候的实际情况就是：决策的时候很鲁莽，计划的时候不周到，执行的时候不坚决，控制的时候不得力，结束的时候当然就无法得到各个方面的满意。

　　我们可以用到项目管理的“1345”分析模型（一个目标、三个管理、四个控制、五个满意）来解决上述问题。项目管理的内容很多，归纳起来，得出这样一个简单可操作的模型：

　　一个目标：作为项目，它的主要目标必须是正确、清晰、可行的。企业家不能像刘泽水那样，简单地下个无边界的命令，而不管能不能实行。

　　三个管理：资源管理、沟通管 理、风险管理。资源管理就是对可操作的资源进行适当地调配。沟通管理是指对项目的实施和反馈环节进行管理。风险管理是对降低项目风险、最大程度达到项目目 标实现的管理。不仅要给任务，还要给资源。其实，我们要向诸葛亮学习，将士出征，情况有变怎么办，联系不上怎么办？事先都要估计到，给个“锦囊”，到了关 键时刻打开，也就是项目中的应急方案。

　　四个控制：项目范围、项目时间、项目质量、项目成本。如何来评价一个好项目，四个字“多、快、好、省”。项目完成的工作多；有效时间内的工作业绩大；项目质量高；成本低，用最低的成本完成任务。控制好这四个因素，是项目成功完成的关键。

　　五个满意：组织获益、客户满意、相关利益者满意、成员愉快、项目经理满意。

　　战场上《集结号》已经画上了句号，但商场上的《集结号》还在不断上演，如果我们的领导者多一些智慧，少一些鲁莽，学一点项目管理，哪怕只花10分钟，了解一下上面这个模型，在我们事业的发展中，相信《集结号》这样的悲剧一定会大为减少！

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和其他相关的人员。一般该会议为４小时。

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

什么是Scrum[转载]

Scrum是一种灵活的软件管理过程，它可以帮助你驾驭迭代，递增的软件开发过程。这个轻量的过程可以作为包装器，也就是说你可以把Scrum与其它灵活的过程框架组合起来，比如说RUP。

RUP（Rational Unified Process，Rational 统一过程），是一种被广泛使用的软件过程框架。它可以很好地迎合你的软件开发过程的需要，还可以容纳其他技术。Scrum是一系列有趣的，用来包装灵活软件项目的项目管理模式。

Scrum 提供了一种经验方法，它使得团队成员能够独立地，集中地在创造性的环境下工作。它发现了软件工程的社会意义。这一过程是迅速，有适应性，自组织的，它代表 了从顺序开发过程以来的重大变化。Scrum认为软件的开发不应使用和一般制造业相同的方法，也就是不应采用一种反复的模式。这种重复使得输入和输出参数 更加容易预测和描述，但这并不是当今软件工程的有益目标。现代软件工程的主要挑战包括上市时间，投资回报，以及影响顾客的需要等。RUP和其他敏捷软件工 程过程能够很好地迎接这些挑战。

Scrum区别于其他开发过程之处是什么？最显而易见的不同将是每天的短会，通常在每天的同一时间在同一个房间内举行。这个会议也叫Scrum，在会议中每个团队成员仅就以下三点发言：

自上次Scrum会议后你做了什么？
从现在到下次Scrum会议的时间里你准备做什么？
你在工作中遇到了哪些困难？

Scrum团队的组成
由 于一个Scrum团队最多由7人组成，会议应当不超过15分钟。Scrum管理者*主持会议，并且对整个项目的成败负责。他倾听每个成员的发言并设法解决 会议中提到的各种障碍。Scrum管理者在会上对障碍提出即时的解决方案或指导，使团队不断向着目标前进。Scrum会议不同于项目会议，对团队来说，它 起到了快速简报的作用。如果问题得不到解决，团队成员应向Scrum管理者或大项目成员提出质疑。

只有团队成员可以在Scrum会议上发言，但是允许有旁听者。对于人数多于7人的项目团队，Scrum建议与其扩大团队规模不如将团队分组。分组可 依据功能，结构主体，或者应用，包括子应用等进行。分组后各个子团队就可以并行工作了，而且Scrum管理者可以通过Scrum会议对各个子团队的工作进 行同步。Scrum甚至可以兼顾在其他地方工作的团队成员。

Scrum团队不止是一个程序员队伍，它由各种背景下的不同角色组合而成，包括商业分析者，设计师，程序员和测试者等等。更多时候，成员可以身兼多职；正确的组合决定了团队的能力和效率。

项目规划
Scrum的迭代过程被称为“疾跑”，时间为30天。在RUP中，迭代过程通常在2至6周之间，每次“疾跑”都以获得可执行可测试的代码为结束。

产品拥有者持有产品订单，他控制并区分功能的开发次序，但是工作量的评估是由Scrum团队来完成的。产品风险的所有承担者，包括Scrum团队和产品所有者，共同检视订单，然后根据优先级次序决定先开发哪一功能。除去优先级，RUP的迭代规划过程也是基于风险的。

现在团队定义的“疾跑”目标已经成为了进展控制的指导。“疾跑”过程一旦开始，团队全部与外界的交流都必须经由Scrum管理者进行。Scrum管理者务必保证团队能够专心于既定目标而不受外界干扰。

Scrum团队持有自己的“疾跑”订单，上面记录了更多关于待实现目标的具体任务的细节。在团队对“疾跑”的作用有更多了解以后，团队成员就可以调整原始的产品评估，并将“疾跑”过程中获得的信息加入到产品订单中。这些做法对Scrum进度回溯都是有益的。

Scrum团队由每天的Scrum会议，每月的“疾跑”计划和“疾跑”审查会议紧密相连，鉴于此，整个组织必然存在一种纵向的透明度。这就使得组织 上的问题和挑战清晰明显。由于团队成员都亲自观察整个项目，交流也就变得简短，迅速和有效。团队是自组织的，着眼于“疾跑”的目标，这样就最大限度发挥了 每一个团队成员的作用。Scrum管理者充当一个问题和交流的“票据交换所”，而不是一个控制整个团队的老板。

“疾跑”审查会议持续半天。在会上，团队向项目的风险承担者展示完成的功能模块。团队按照既定的“疾跑”目标来演示完成的内容。

1. StarUML

2. Netbeans UML Plugin

3. Acceleo

4. ArgoUML

5. BOUML

6. Eclipse UML2 Tools

7. Umbrello UML Modeller

8. Frame UML

9. UMLet

10. TinyUML

11. Taylor

12. Papyrus UML