系统介绍

l  TeamLab 是一个免费开源的商业协作和项目管理的平台。TeamLab 主要功能包括：项目管理、里程碑管理、任务、报表、事件、博客、论坛、书签、Wiki、即时消息等等。

l  Redmine 是一个开源的、基于Web的项目管理和缺陷跟踪工具。它用日历和甘特图辅助项目及进度可视化显示，同时它又支持多项目管理。Redmine是一个自由开放 源码软件解决方案，它提供集成的项目管理功能，问题跟踪，并为多个版本控制选项的支持。

部署环境

TeamLab

windows server， .net framework 3.5

RedMine

任意操作系统 Ruby Mysql Apache

软件结构

l  TeamLab系统基于大量C#第三方开源类库开发而成，代码工程比较复杂，支持扩展的能力比较强，基于sqlite或mysql两种数据库。

l  RedMine系统基于ruby on rails mvc框架开发，代码及数据结构比较简洁，功能相对简单，基于mysql或postgresql数据库。

试用情况

l  TeamLab 可定制性和扩展性更强一些，社区、IM、讨论方面的优势明显，TeamLab安装比较容易。

l  RedMine 试用感觉更像jira，常用的项目管理、缺陷管理功能非常相似，没有IM，论坛功能较差，安装步骤繁琐，中间会遇到很多ruby环境的问题。

软件集成度

TeamLab

l  集成LDAP认证，需要改造，而且用户多了，很多地方有问题。

l  中文支持困难。

RedMine

l  集成LDAP较容易，用户选择方面比较好用，暂时没发现问题。

l  默认支持多语言。

综合对比

　　一、保持简单

　　Powerpoint幻灯片本身从来不是演示的主角，听众才是主角。幻灯片仅仅是人们用来帮助倾听、感受或接受您传达的信息，所以不要让幻灯片喧宾夺主，不要制作得过于繁杂或充满图表垃圾”，应该力求简洁。

　　幻灯片应该留有大量的空白空间，或实体周围的空间。不要被迫用妨碍理解的标识或其它不必要的图形或文本框来填充这些空白区域。幻灯片上的混乱越少，它提供的视觉信息就越直观。

　　二、限制要点与文本数量

　　演示的对象是观众。但用一条又一条的要点令观众生厌可没有好处。应用文本也要遵循这一原则。最优秀的幻灯片可能根本没有文本。由于今天人们过于 依赖文本型幻灯片，这听起来可能有些荒唐，但如果没有演示者的解说，再优秀的PowerPoint幻灯片也几乎没有什么意义。记住，幻灯片的目的在于支持 解说者的叙述，而不是使解说者成为多余的人。

　　经常听到有人这样说：“对不起，我没有看到您的幻灯片。听说它很不错，您可以把您的PowerPoint幻灯片发给我吗?”但如果它们是不错的幻灯片，没有您的解说，它们就没有多大用处。

　　所以除了Powerpoint幻 灯片以外，最好还要准备一份书面资料，强调并详细说明演示中的内容。向观众发送说明幻灯片的详细书面宣传材料，比仅用 PowerPoint幻灯片，更利于观众理解演示的内容。在演示完成以后，再向观众发放一份详细的宣传材料或印刷物，您就不必用大量文本来填充 PowerPoint幻灯片。

　　我们将在下面的交付部分说明更多细节，但只要涉及到文本，请记住一点，绝不能将背朝向观众，逐字阅读幻灯片上的文字。

　　
　　这帧幻灯片很普通，但这样的配色和拥挤的排版让人觉得它更像是一个视力检查表。

　　
　　文字过多，让人昏昏入睡

　　
　　推荐使用上面这类针对性强的幻灯片

　　
　　这样的效果也许更能突出主题

　　三、限制过渡与动画

　　制作Powerpoint演示的时候加入一些动画当然不错，但应坚持使用最精致、专业的动画。应该谨慎使用动画与幻灯片过渡，仅仅突出要点就可以了。

　　对于要点来说，使用简单的从左至右显示的动画就行了，但移动(Move)或漂动(Fly)动画就显得过于沉闷与缓慢(然而，今天许多演示还使用 这种形式的动画)。一帧接一帧的动画很快就会让听众感到厌烦。至于幻灯片之间的过渡，只需要使用二到三种类型的过渡特效，不要在所有幻灯片之间添加特效。

　　四、使用高质量的图片

　　使用高质量的图片，包括照片。您可以用数码相机拍摄高质量的相片，购买专业图库，或使用网络上的大量优质图像资源。(但要小心版权问题。)决不要地将小尺寸、低分辨率的相片简单拉伸，使它适合幻灯片的布局——这样做只会进一步降低图片的分辨率。

　　避免使用PowerPoint剪贴画或其它卡通式的艺术线条。而且，如果软件中包含这些内容，观众以前就看过无数次。在1993年使用这些内容 可能会让人感兴趣，但如今还应用剪贴画则会降低制作人的专业水准。当然也有例外情况，并不是所有的PowerPoint剪贴画都让人生厌，但还是小心谨慎 地使用它们为 好。

　　我经常在幻灯片中使用人物图片，因为人物照片有助于增加观众与幻灯片之间的情感联系。如果相片处于次要地位，我就降低不透明性，并在 Photoshop中增加一个高斯模糊或动态滤镜;如果相片位于主要区域，我希望观众注意它(例如产品图片)，那么图片可以变得更为显著，且不必要多少 (或根本不需要)文字说明。

　　
　　避免使用这类低劣的剪贴画

　　
　　这幅经过编辑的库图片更为显著专业。

　　
　　在这个字幕幻灯片中，图片占主要地位。

　　
　　这个幻灯片来自同一演示，首先经过Photoshop的编辑，图片变得次要，并被推到背景部分

　　五、建立一个视觉主题，但避免使用PowerPoint模板

　　很明显，在整个演示中，您需要一个一致的视觉主题，但PowerPoint中的大多数模板观众已经看了无数次(另外，用模板开始演示的效果并不那么强烈)。

　　观众期待看到一个包含新鲜内容(至少对他们来说是这样)的独特演示;此外，观众为什么要参加您的演示呢?没有人会对千篇一律的演示感兴趣，因此我们必须避免使用辅助性的图片，如随处可见的PowerPoint设计模板，它只能说明演示非常刻板，或提前就设计完成了。

　　您可以制作自己的背景模板，它能够更为适应您的需要。然后您可以将这个PowerPoint文件保存为设计模板(扩展名为.pot)，这个新模板就会出现在微软标准模板中，方便以后使用。您还可以在线购买专业的模板。

　　六、应用适当的图表

　　经常问自己这个问题：“我需要多少细节?”一般制作者害怕在幻灯片的图表中加入过多的数据。有几种以图表形式显示数据的方法;以下是需要紧记的工具：

　　
　　圆饼图：用于显示比例。将分割块的数目限制在4-6块，用颜色或碎化的方式突出最重要的块。

　　
　　柱状图：用来显示一段时间内数量的变化情况。将竖条的数目限制在4-8条最佳。

　　
　　条形图：用来比较数量。例如，比较公司四个部门的销售额。

　　
　　曲线图：用于说明趋势。例如，上面这幅简单的曲线图说明我们的销售在逐年增长。增长趋势良好。最后的箭头强调一个问题：我们将来的发展似乎不错。

　　通常来说，表格最适于比较并行数据资料。

　　但是，表格可能缺乏视觉效果。例如，如果您希望说明您们做出的贡献显著高于其它两个部门，最好以条线图(见下图)的形式进行说明。但如果您希望弱化您们的贡献低于其它部门这一事实，用表格传达信息就可减少人们的注意力或感情色彩。

　　七、使用好色彩

　　色彩激发情感。颜色可传递感情。合适的颜色具有说服与促进能力。研究表明色彩能够提高兴趣，改善学习过程中的理解与记忆能力。

　　您不必成为颜色理论专家，但至少了解一些这方面的知识有会好处。一般颜色可分为两类：冷色(如蓝和绿)和暖色(如橙或红)。冷色最适合做背景 色，因为它们不会引起我们的注意。暖色最适于用在显著位置的主题上(如文本)，因为它可造成扑面而来的效果。因此，绝大多数PowerPoint幻灯片的 颜色方案都使用蓝色背景，黄色文字也就不足为奇了。但您不必强迫使用这种颜色方案，也可以做一些改变，使用其它的颜色。

　　如果您将在暗室(如大厅)中进行演示，使用深色背景(深蓝、灰等)再配上白或浅色文字可取得不错的效果。但如果您计划将灯打开(这是相当明智 的)，白色背景配上深色文字处理会得到更好的效果。在灯光明亮的房间内，用深色背景配浅色文字效果不佳，但浅色背景配深色文字会更好地维持视觉效果。

　　八、选择适当的字体

　　字体可传递微妙的信息，所以我们要仔细选择字体。在整个幻灯片演示中使用相同的字体，补充字体不要超过两个(如Arial和Arial粗体)。 确信自己了解 serif字体(如Times New Roman)和sans-serif字体(如Helvetica或Arial)之间的差异。

　　含有大量文本的材料大多用serif字体。据说这种字体在小磅值下更易于阅读，但对于屏幕演示而言，由于幻灯机的分辨率相对较低，使用这种字体可能不够清晰。

　　sans -serif字体一般用来制作PowerPoint演示，但应尽量避免使用千篇一律的Helvetica字体。我经常使用Gill Sans字体，因为它界于serif字体与sans-serif字体之间，看起来专业而友好，并具有“交谈效果”。不管使用哪个字体，都必须保证在房间后 面看得清文字。

　　Times

　　Arial黑体;Arial

　　九、应用视频或音频

　　适当的时候使用视频或音频。应用视频短片对具体的例子进行说明，可提高主动认知能力，这是人们自然的学习方式。在PowerPoint中，不必 利用应用程序或打开录像机就可使用视频短片。应用视频不仅可以更好地说明您的观点，还可以作为变换口味的手段，因而能够激发观众的兴趣。

　　您还可以在幻灯片中使用音频剪辑(如采访过程)。但避免使用PowerPoint中的嘈杂音效(如过渡幻灯片时使用的号角声或掌声)。在动画中使用过量的声效肯定会使观众丧失兴趣。

　　十、花时间对幻灯片进行细分

　　根据多媒体学习理论的细分原则，当信息以小块或小片段的形式呈现时，更易于人们理解。离开幻灯片视图进入幻灯片细分视图，您可以查看演示播放的 逻辑流程。在这个视图中，您可以将一个幻灯片分割成二个或三个幻灯片，这样幻灯片就具有更加自然与逻辑化的流程或进程。您还可以从观众的角度了解幻灯片的 总体效果。并且发现更多可以被删除的无关紧要的视觉数据，增加幻灯片的视觉清晰度，提高信息传达效果。

　　
　　PowerPoint中的幻灯片细分视图

　　作者简介：Garr Reynolds当前在关西外国语大学任管理学副教授，她在那里讲授营销学、全球营销与多媒体演示设计。Garr是日本社区的活跃成员，并经常主持与设 计、品牌和高效企业沟通有关的主题。除网站外，他还有一个博客——演示经典——为专业演示设计提供启示。

http://bbs.scmlife.com/thread-16353-1-1.html k/ o3 Y6 g) j" ^0 z2 E) o( v9 L5 O
我在做配置管理以前做过两年的测试，期间做过两家公司的iso 9000的内审员，然后老板觉得我比较有耐心，所以赶鸭子上架，和前任学习拉一周，我就是配置管理拉，然后不知不觉，已经6年拉，总结一下，看看会需要些什么呢？
1、软件公司的开发流程，对软件工程一定要熟悉，尤其是开发模型，你不能保证公司的所有项目使用一个模型。比如：瀑布、迭代或者极限编程。只有熟悉这些开发模型，你才能参与到公司的流程制定中去。
2、 熟悉一些标准，比如：iso 9000和cmmi。一个公司想要发展大，想要稳定，就一定会有一套稳定的流程。而熟悉标准，会更有利于你理解和说服你的同事。记得以前一个同事说过这样 一句话，一个公司想要长大，那一定必须是一头小象而不能是一只大蚂蚁。而一个做有流程，愿意将公司的事情流程化的公司才能保证不因人成事，才能长大。. @5 "9 E: Q( L0 j1 ~
3、沟通能力。配置管理员的工作就是沟通协助需求、开发及测试人员工作。而一个新的项目的建立意味这大家都是新人，来自不同的行业不同的公司，公司文化不 同，做事的方法也不同，你只有有好的沟通能力，才能说服项目经理支持你的工作，才只能说服开发测试人员按你要求的流程工作。
4、编程能力。想做好配置管理，你就不得不编写一些配置脚本，以方便开发测试人员，同时减少自己的工作量。
5、数据库知识。一般来说配置管理员，同时要管理BUG跟踪或需求管理的系统，那免不了老板会让你提供一些统计数据，所以数据库知识也是必不可少的。
6、系统知识。多说公司的配置管理员还要负责开发测试环境的维护，那么有系统知识，无疑可以减少你求助的机会。
现在说说我做过什么？& g! @2 `9 [: f+ ]5 g! z4 "/ f. q
一、上海项目的时候，只是负责系统的配置管理，包括代码编译，上线，这个系统比较大，但是还好，我是从别人手上接手的，所以还在顺序。
二、集团项目的的时候，我同时维护9个省的测试上线环境。
由于用户一直是用unix系统，所以顺便学会拉shell ，学会来在ibm，hp，sun的小型机上安装配置软件。
尤其是bes521的安装，简直是无言啊？宝 蓝从总部派人过来，现场安装，配置、测试，美国总部修改bug，然后打补丁，终于，我写了一本安装手册，两年后公司同事还在用。安装ibm的 websphere的时候，我发现需要打操作系统补丁，于是比较傻瓜的我，安装拉最新版的补丁，要命的是这个websphere比较变态，尽然只能用它指 定版本，所以到现在我都恨websphere啊。
要说最大的收获，就是在压力下面，我做事情很负责，我的努力让公司项目经理面对甲方也很硬气。! b  ^/ I7 E/ s" V
三、做公司的openboss系统。这个系统对我的锻炼很大，工作如下：/ d2 ?% d/ f1 K& d0 Y) I
1、写cvs脚本，保证代码能在提交的时候,同时建立开发和构建分支，同时不能是分支之上建立分支。
2、和一个没有任何配置管理经验的开发团队扯皮，扯开发流程，扯目录结构，扯Makefile模板，扯代码命名规范，然后想办法让他们执行。9 U1 J- G8 r0 ^2 D% i+ N6 Z
这个系统很大，到今天，已经有11个移动，3个网通，3个电信在使用。分出来的系统现在也有15个拉，仅仅营业和账务两个系统，unix后台就有500多个动态库，当时扯皮，现在受益。
3、和总工办 一起搞unix主机下的编译选项，由于用户的环境复杂，所以要求做到，代码写出来后，可以跨cpu，跨操作系统、跨中间件、跨数据库。所以这个过程让我对 unix下的编译器熟悉起来，不然无法做到。让我自豪的是到现在，开发人员只要修改Makefile模板很少的地方，就可以跨平台编译拉。
4、编写自动编译脚本。通过我们开发的自动编译系统，开发人员只要在浏览器中提交编译单就可以自动编译拉。而如果开始的时候，如果没有将目录规划好，我想自动编译就是无源之水。6 H& H1 ?% b; n5 N
这个系统我们web部分用jsp，unix用tcl/tk脚本。现在已经集成到QCS的源码管理中，还在改进，还在使用。7 r) H# K. ~- i6 r

四、公司的QCS系统（质量控制系统）。
这是一个配置管理系统，通过rsh将CVS和QCS结合在一起，用jsp和oracle的存储过程开发，其中包括：需求管理、功能点管理、任务管理、源码管理、bug管理、工程故障管理、接口管理、数据库变更管理、版本管理、发布管理、回退管理等模块的系统。2 z( T! {' a7 c* J: A0 v" M

五、参加公司的EPG小组，并且以配置管理员的身份参与评审。+ E* F) S  j( B' |# F# u  ^
公司两年前已经通过CMMI 5的认证。我加入公司的公司只是通过拉CMM 2级。后来由于甲方的要求，公司开始CMMI的认证。这中间有大量的文档要写。尤其是配置管理员，在几乎所有的过程中，都要参与评审，所以准备工作做拉好 久。到 CMMI 5级的时候，就要提供大量的统计数据来说明持续改进的结果，所以对QCS就需要不少地方做改动，来收集数据。还好公司一直注意这块，我们的各种脚本，模 板，都是尽量的优化以满足开发测试人员的需要。所以后来的评审中基本没有费什么事就过拉。* G6 J3 w5 "# z
( [" N- P( V% F4 "$ d, `
在这个项目中，让我对配置管理中的很多概念理解很深。尤其是在评审的时候，将自己平时做的工作用CMMI的语言讲解，感觉的确是锻炼人。
- a% k3 H% s/ Q5 S# ^, |+ T
这中间的很多事情，我的感谢我的师傅，虽然他比我年龄还小，而且也没有带我很久，但是很多问题都是和他讨论中加深理解的，不管是从技术上，还是为人都让我学之不尽啊。
1 h( "  C) "8 r  t- @7 C
要做好配置管理，一定要耐心、细心、恒心。
冰冻三尺非一日之寒。, H3 N' z: f+ I  y' V) K
* j; V, r: J* w, x; P9 p! ]
希望以上内容能给新入行的同行一点帮助。
原文：

2、往版本库中添加新的文件

3、将改动的文件提交到版本库

4、加锁/解锁

  svn lock -m "LockMessage" [--force] PATH
   例如：svn lock -m "lock test file" test.php
svn unlock PATH

5、更新到某个版本

6、查看文件或者目录状态

  1）svn status path（目录下的文件和子目录的状态，正常状态不显示）
   【?：不在svn的控制中；M：内容被修改；C：发生冲突；A：预定加入到版本库；K：被锁定】
  2）svn status -v path(显示文件和子目录状态)
   第一列保持相同，第二列显示工作版本号，第三和第四列显示最后一次修改的版本号和修改人。
   注：svn status、svn diff和 svn revert这三条命令在没有网络的情况下也可以执行的，原因是svn在本地的.svn中保留了本地版本的原始拷贝。
简写：svn st

7、删除文件

8、查看日志

9、查看文件详细信息

10、比较差异

11、将两个版本之间的差异合并到当前文件

12、SVN 帮助

——————————————————————————

以上是常用命令，下面写几个不经常用的

——————————————————————————

13、版本库下的文件和目录列表

14、创建纳入版本控制下的新目录

15、恢复本地修改

16、代码库URL变更

17、解决冲突

18、输出指定文件或URL的内容。

　　如图1所示，敏捷开发过程经历需求调研，用例分析和用例分解，进入开发迭代阶段。在每个迭代过程中，可以采用以下步骤来保证和提高整个项目的代 码质量：统一编码规范、代码样式;静态代码分析(staticcodereview);单元测试;持续集成;代码评审和重构 (Review&Refactor)。下文将针对每个步骤和其所使用的工具、方法进行详细描述。

　　图1.敏捷开发中的Java代码质量保证步骤
原文：http://soft.chinabyte.com/182/11155182.shtml

为了不落后他人，于是我也开始学习Scrum，今天主要是对我最近阅读的相关资料，根据自己的理解，用自己的话来讲述Scrum中的各个环节，主要 目的有两个，一个是进行知识的总结，另外一个是觉得网上很多学习资料的讲述方式让初学者不太容易理解；所以我决定写一篇扫盲性的博文，同时试着也与园内的 朋友一起分享交流一下，希望对初学者有帮助。

 什么是敏捷开发？

敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。

怎么理解呢？首先，我们要理解它不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发；

为什么说是以人为核心？

我们大部分人都学过瀑布开发模型，它是以文档为驱动的，为什么呢？因为在瀑布的整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是 根据文档进行开发的，一切以文档为依据；而敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核 心。

什么是迭代？

迭代是指可以生产或开发出一个可以交付软件的产品，这样的一个周期就是一次迭代的过程。

关于Scrum和XP

前面说了敏捷它是一种开发方法，也可以说是一种开发流程，但是它没有明确告诉我们到底采用什么样的流程，而Scrum和XP就是敏捷开发的具体流程了，你可以采用Scrum流程也可以采用XP流程；Scrum和XP的区别是，Scrum偏重于过程，XP则偏重于实践，这里我主要讲Scrum。

什么是Scrum？

Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。

而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。

【Scrum开发流程中的三大角色】

产品负责人（Product Owner）

主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。

流程管理员（Scrum Master）

主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。

开发团队（Scrum Team）

主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。

Scrum流程图

//------------------------

下面，我们开始讲具体实施流程，但是在讲之前，我还要对一个英文单词进行讲解。

什么是Sprint？

Sprint是短距离赛跑的意思，这里面指的是一次迭代，而一次迭代的周期是1个月时间（即4个星期），也就是我们要把一次迭代的开发内容以最快的速度完成它，这个过程我们称它为Sprint。

如何进行Scrum开发？

1、我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的；

2、Scrum Team根据Product Backlog列表，做工作量的预估和安排；

3、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；

4、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；

5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天 要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）；

6、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可 以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本 发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；

7、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；

8、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；

下面是运用Scrum开发流程中的一些场景图：

原文：http://www.congci.com/item/scrumarticle

回到产品设计本身，
早期“阶段性”的流程方式给我们产品开发和设计，带来了无尽的“返工”和低质量设计。往往前一个“阶段”的细节失误，就能导致后一个阶段的彻底垮工。
特别是我们从目录网站走到内容网站，又走到了今天的社区，网站本身的跌代性和反复修改变得越来越快。“阶段性”的流程方式无法“多团队同时协作”，导致的低效率，越来越凸显。

于是我们开始针对“产品更新快”、“迭代频繁”、“多团队协作”，等特性需求而改进的一些产品设计流程。这样的流程从大体上可以分成三个要点：按阶段发展相互依赖 + 表现层和底层相对分离 + 循环渐进反复迭代。

可以尝试用这样的一张草图来表现这种“流程”：

1、产品团队是核心。
产品团队发起项目，做前期的整体调研和评估，确定产品的定位、方向，以及大的产品概念设计。
在这个基础上将所面向的用户群进行大致划分，对不同用户群体的需求进行概要分析和总结。
最后产出：产品的整体框架，重要需求点的业务逻辑。

2、表现层和底层相对分离。
对于研发来说，产品的产出物都是数据。产品架构就是他的底层数据结构，业务逻辑就是他的数据逻辑。（研发我只懂皮毛，具体内容不一定完全正确）
对于设计来说，之前对于用户群的划分、对于需求的分析将演变成未来网站的内容设计；产品架构将演变成网站的信息架构（栏目、布局、导航等），业务逻辑是未来交互设计的依据。
最后，研发的前端的接口和设计的前端开发相结合。

3、这样做最大的好处在于：
业务发展到一定时候，当底层需要升级或者改进，表现层可以不用变化；
如果表现层的设计需要“改版”，底层可以不用变化；
只有当产品方向有变，或者业务逻辑发生变化，才会牵扯到底层和表现层同时变化。

4、按阶段发展相互依赖。
单看产品+研发，或单看产品+设计，每一个从上至下的过程都必须具备先后的阶段性，上一个的过程决定了下一个过程的大致范围，下一个过程影响并补充了上一个过程的详细内容。
比如，没有大的产品框架就没有具体的信息架构，在具体的信息架构设计过程中，又会修正并补充整体的产品框架。
再比如，没有需求分析，就不能有具体的内容设计，在具体的内容设计过程中，又会细化需求并有可能合并或者拆分已经修改需求。

5、循环渐进反复迭代。
这一点和第四点有很大的关系，理解这一点可以先看一下Jesse James Garrett 在《THE ELEMENTSOF USER EXPERIENCE》一书中（这是一本每个产品设计者都应该阅读的入门好书，中文叫《用户体验的要素》，由Angela翻译，因为我很讨厌这个书名里莫名其妙多了一个“的”字，所以以后我只会引用英文书名。），关于“迭代”的解释：

JJG在把体验分成了战略、范围、结构、框架、表现五个层面。我认为这五个层在细化的过程中，已不很适合如今的互联网产品设计，而且内容过于粗略，属于概念性质的东西，很难应用到操作层面。但，他在这里讲述这五个层在具体应用中的迭代关系，可以应用现在的设计中。

Angela是这样翻译的：“你应该计划好你的项目，让任何一个层面中的工作都不能在其下层面的工作完成之前结束。… 在我们知道基本形状之前，不能为房屋加上屋顶。… 要求每个层面的工作在下一个层面可以开始之前完成，会导致你和你的用户都不满意的结果。… 一个更好的方法是让每一个层面的工作在下一个层面可以结束之前完成”。

拿到这里会有一点小变动，应该这么说：不能完整结束了这个阶段的工作，才开始下个阶段；在下个阶段该结束的时候，完成这个阶段这个阶段的工作。（这也是为了我在前面给“完整”“整体”“大致”等关键词加粗的原因）
比如，不要把需求整理的非常详细以后再去内容设计，只要在内容设计该结束的时候完成需求整理；不要在开始信息架构设计的时候完全确定内容设计，只要在信息架构该确定的时候完成内容设计。也就是说“需求整理在信息架构开始的时候完成即可”。

（当然，这种做法一个更大的问题会出现：文档维护比以往阶段性的方式更繁复。 这一点，后面会详细谈到。 ）

不可分割的“用户调研”
细心的人可能已经看出，上面的设计并没有加入“用户”的内容。没错，上面的图只是在说“设计”，并没有提到用户调研。
用户调研应该贯穿于设计的任何一个环节，在整个设计过程中既起到“引导”的作用，又起到“校验”的功效。加入了对用户的研究以后，整个“迭代的设计过程”才会变得完整和丰满。

事实上这边文章应该属于“迭代设计”的一半内容，在以往的培训中我会加入用户调研部分进去（比如，这张图白板左边是上面的内容，右边就是用户调研加入进去之后的“产品设计”过程。右边的一半内容都是用户调研）。这篇文章就不细说了，《Design IT.》 系列正式完成的时候再补充进去。

原文： http://uicom.net/blog/?p=773

1. 边做边改模型（Build-and-Fix Model）；

2. 瀑布模型（Waterfall Model）；

3. 快速原型模型（Rapid Prototype Model）；

4. 增量模型（Incremental Model）；

5.螺旋模型（Spiral Model）；

6.演化模型(incremental model)；

7.喷泉模型(fountain model)；

8.智能模型(四代技术（4GL）)；

9.混合模型（hybrid model）

1. 边做边改模型（Build-and-Fix Model）
遗憾的是，许多产品都是使用"边做边改"模型来开发的。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改.
在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。
这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：
（1） 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；
（2） 忽略需求环节，给软件开发带来很大的风险；
（3） 没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。

2. 瀑布模型（Waterfall Model）

1970年Winston Royce提出了著名的"瀑布模型"，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。
瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。
瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于：
（1） 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
（2） 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；
（3） 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。
我们应该认识到，"线性"是人们最容易掌握并能熟练应用的思想方法。当人们碰到一个复杂的"非线性"问题时，总是千方百计地将其分解或转化为一系列简单 的线性问题，然后逐个解决。一个软件系统的整体可能是复杂的，而单个子程序总是简单的，可以用线性的方式来实现，否则干活就太累了。线性是一种简洁，简洁 就是美。当我们领会了线性的精神，就不要再呆板地套用线性模型的外表，而应该用活它。例如增量模型实质就是分段的线性模型，螺旋模型则是接连的弯曲了的线 性模型，在其它模型中也能够找到线性模型的影子。

3. 快速原型模型（Rapid Prototype Model）

快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。
显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。
快速原型的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求。

4. 增量模型（Incremental Model）

与建造大厦相同，软件也是一步一步建造起来的。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成.
增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付 产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。但是，增量模型也存在以下缺陷：
（1） 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
（2） 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。
在使用增量模型时，第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。
例如，使用增量模型开发字处理软件。可以考虑，第一个增量发布基本的文件管理、编辑和文档生成功能，第二个增量发布更加完善的编辑和文档生成功能，第三个增量实现拼写和文法检查功能，第四个增量完成高级的页面布局功能。

5.螺旋模型（Spiral Model）

1988年，Barry Boehm正式发表了软件系统开发的"螺旋模型"，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。
螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：
（1） 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；
（2） 风险分析：分析评估所选方案，考虑如何识别和消除风险；
（3） 实施工程：实施软件开发和验证；
（4） 客户评估：评价开发工作，提出修正建议，制定下一步计划。
螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。但是，螺旋模型也有一定的限制条件，具体如下：
（1） 螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。
（2） 如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。
（3） 软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险
一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造 原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。

6.演化模型(incremental model)
主要针对事先不能完整定义需求的软件开发。用户可以给出待开发系统的核心 需求，并且当看到核心需求实现后，能够有效地提出反馈，以支持系统的最终设计和实现。软件开发人员根据用户的需求，首先开发核心系统。当该核心系统投入运 行后，用户试用之，完成他们的工作，并提出精化系统、增强系统能力的需求。软件开发人员根据用户的反馈，实施开发的迭代过程。第一迭代过程均由需求、设 计、编码、测试、集成等阶段组成，为整个系统增加一个可定义的、可管理的子集。
在开发模式上采取分批循环开发的办法，每循环开发一部分的功能，它们成为这个产品的原型的新增功能。于是，设计就不断地演化出新的系统。 实际上，这个模型可看作是重复执行的多个“瀑布模型”。
“演化模型”要求开发人员有能力把项目的产品需求分解为不同组，以便分批循环开发。这种分组并不是绝对随意性的，而是要根据功能的重要性及对总体设计的基础结构的影响而作出判断。有经验指出，每个开发循环以六周到八周为适当的长度。

7.喷泉模型（fountain model, (面向对象的生存期模型, OO模型)）

喷泉模型与传统的结构化生存期比较，具有更多的增量和迭代性质，生存期的各个阶段可以相互重叠和多次反复，而且在项目的整个生存期中还可以嵌入子生存期。就像水喷上去又可以落下来，可以落在中间，也可以落在最底部。

8.智能模型(四代技术（4GL）)
智能模型拥有一组工具（如数据查询、报表生成、数据处理、屏幕定义、代码生成、高层图形功 能及电子表格等），每个工具都能使开发人员在高层次上定义软件的某些特性，并把开发人员定义的这些软件自动地生成为源代码。这种方法需要四代语言 （4GL）的支持。4GL不同于三代语言，其主要特征是用户界面极端友好，即使没有受过训练的非专业程序员，也能用它编写程序；它是一种声明式、交互式和 非过程性编程语言。4GL还具有高效的程序代码、智能缺省假设、完备的数据库和应用程序生成器。目前市场上流行的4GL（如Foxpro等）都不同程度地 具有上述特征。但4GL目前主要限于事务信息系统的中、小型应用程序的开发。

9.混合模型（hybrid model）
过程开发模型又叫混合模型（hybrid model），或元模型（meta-model）,把几种不同模型组合成一种混合模型，它允许一个项目能沿着最有效的路径发展，这就是过程开发模型（或混 合模型）。实际上，一些软件开发单位都是使用几种不同的开发方法组成他们自己的混合模型。

各种模型的比较
每个软件开发组织应该选择适合于该组织的软件开发模型，并且应该随着当前正在开发的特定产品特性而变化，以减小所选模型的缺点，充分利用其优点，下表列出了几种常见模型的优缺点。
各种模型的优点和缺点
瀑布模型 文档驱动 系统可能不满足客户的需求
快速原型模型 关注满足客户需求 可能导致系统设计差、效率低，难于维护
增量模型 开发早期反馈及时，易于维护 需要开放式体系结构，可能会设计差、效率低
螺旋模型 风险驱动 风险分析人员需要有经验且经过充分训练

原文：http://blog.csdn.net/sunboy_2050/archive/2010/06/16/5674328.aspx

误区1：在项目的需求分析阶段，开发方与客户方在各种的问题的基本轮廓上达成一致即可，具体细节可以在以后填充。因为无论开始时有多么细致，以后对 需求的修改几乎是必然的。分析：这是一种非常危险的思想。实际上许多软件项目失败的最主要的原因就是需求阶段对问题的描述不够细致，导致后来预算超出或者 时间进度达不到要求。正确的做法是：在项目需求分析阶段，双方必须全面地尽可能细致地讨论项目的应用背景、功能要求、性能要求、操作界面要求、与其他软件 的接口要求，以及对项目进行评估的各种评价标准。并且，在需求分析结束以后，双方还要建立可以直接联系的渠道，以尽早地对需求变动问题进行沟通。(范围的核实和项目验收都要根据范围基准进行。因此前期的范围说明书和范围的基线至关重要)

误区2：软件项目的需求可以持续不断的改变，而且这些改变可很容易地被实现。分析：的确，在具体实际中由于种种原因客户方很难在需求分析阶段全面而 准确地描述所有问题。随着开发进度的推进，往往会有一些需求的改变。而现代软件工程理论也利用软件的灵活性特点通过各种方式来适应这种情况。不过，这并不 表明“软件项目的需求可以持续不断的改变，而且这些改变可很容易地被实现”。实践表明：随着开发进度的推进，实现软件需求更改所需要的代价呈指数形式增 长。假定在需求分析阶段实现需求更改需要花费1倍的代价；那么，在系统设计和编码阶段，需要花费1.5-6倍的代价；在系统测试阶段需要花费10-20倍 的代价；在软件版本发布以后，甚至可能要花费60-100倍的代价。由此可见，在项目开展过程中，软件需求的改变应当尽量早地提出。这样才可能花费少，容 易被实现。(不应该称为误区了，现在估计谁都不会认为需求可以持续不断改变)

误区3：软件程序主要由代码组成，因此编码阶段是整个软件项目的最重要的阶段，应该给与大量的时间，并且集中主要的资源。分析：与以前相比，由于软 件的规模和复杂度的增加，以及半自动化软件代码开发平台的出现，现代软件项目管理的中心发生了转移——不是着重编码阶段，而是着重系统总体/详细设计阶 段。一般说来，在现代软件项目管理中各种资源的合理分配比例是：项目论证、风险评估阶段3% ，项目需求分析阶段8%，系统总体/详细设计阶段45%，编码阶段10%，系统测试阶段34%。(这个跟软件项目的规模密切相关。对于规模小于2万行代码的，或者说采用敏捷或快速开发的，或者说架构已经确定的改进型号项目，编码时间至少要占30%；而对于源代码规模超过50万行的大型软件项目,重点则是在需求和系统设计上面，编码时间一般为10%)

误区4：为了便于代码的维护修改，在系统的详细设计阶段文档工作应该做到写出所有程序的伪码。分析：通常伪码的最大作用是对程序的算法流程进行描 述，便于人们深入了解程序的功能和实现过程。可见，在一定程度上伪码的确有利于对程序代码的维护和修改。但是，我们知道为了保证项目文档和程序代码的一一 对应关系，维护程序代码的时候同时需要对项目文档进行维护。伪码和程序代码是非常接近的，对伪码进行维护的话，相当于进行了2倍的程序代码维护。工作量是 很大的。所以切合实际的方式应该是对一般的程序文档做到程序流程图即可，对于涉及了较复杂算法的才需要伪码。(应该深刻理解源代码就是设计的一些重点观点和思路，因此详细设计输出的代码模型一般是不抛弃的，编码人员可以直接在该代码模型基础上进行编码)

误区5：既然在项目人员配置中设置了专门的测试人员，那么软件所有的内部测试工作全部应该由测试人员完成。分析：软件程序测试可以分为“白盒法”和 “黑盒法”两种方式。由于使用“白盒法”对测试人员各方面素质的种种要求，在进行程序测试时测试人员总是最优先使用“黑盒法”。他们的工作方式往往是先对 程序进行“黑盒法”测试；如果测试没有通过，不得已这才考虑对程序代码进行“白盒法”测试。显然，这种对“白盒法”有意无意的“逃避”，对软件的可靠性和 稳定性构成了威胁。如何解决这个问题？一方面需要提高对测试人员的要求，另一方面也需要程序员完成部分的“白盒法”测试（实际上，程序员往往也是进行“白 盒法”测试的最佳人选）。(估计很少有人这样认为，所以不应该称为误区)

误区6：软件项目管理只是相关技术部门的事情，与公司其他部门无关。分析：在竞争日益激烈的今天，软件项目规模大、复杂度高而且时间要求紧迫。要想 提高公司的软件项目管理水平，这就需要提高公司的整体参与意识，需要公司各个部门协同作战。例如需要会计部门协助进行项目预算，财务管理和费用控制；需要 研究部门（技术委员会）指派专家协助进行各种风险评估，提供技术指导；需要后勤部门提供各种保障。(干系人管理很重要,同时CMMI强调的集成项目管理也说明了这一点)

误区7：在开发进度滞后的情况下，可以聘请更多的程序员加入到开发团队中，通过增加人力资源来赶上进度。分析：在注重团队开发的时代，开发方应该根 据目前的软件项目管理水平慎重考虑这个做法。如果新加入的程序员对目前软件项目的应用行业有一定了解，并且可以很快适应了开发方的项目管理方式、软件开发 风格、团队协作氛围；那么“新人”的加入是有益的。否则，可能会“好心好意做坏事”。因为尽管其个人能力很高，但是为了使其与大家一起协同工作，开发团队 不得不分出人手对其进行与项目有关的技术/业务培训，更重要的（也是难度最大的）是还要引导其融入团队。这可能需要花费开发团队许多时间和精力，很有可能 使项目进度更慢。(可以辩证的看，组织的成熟度越高，复用越高，该方法才是可能的方法)

误区8：技术骨干应该成为项目的项目经理，项目经理一定是所有项目成员中薪水最高的。分析：在“软件作坊”时代，这是一种普遍使用而且效果不错的方 法；而在“软件工厂”时代，这种方法却带来各种问题，有时甚至直接导致项目失败。究其原因这主要是因为随着现代软件开发分工的细化，对项目经理的要求也发 生了根本的改变——最注重的不是其对某项专业技术的掌握程度，而是其组织、领导、协调开发团队的能力（当然，可以两者均突出最好）。至于项目经理的薪水问 题，这和定薪制度有很大关系。通常，项目经理执行的是管理人员的薪酬体系，而其他人员执行的是技术人员的薪酬体系。项目经理的薪水在项目成员中是比较高 的，但不一定是最高的。有时候，为了激励技术人员，项目中的技术骨干得到的酬劳比项目经理要高。(这里跟工种无关，更相关的是效率和产出,但去很难推行)

误区9：只有项目经理以及部门主管才会关心项目整体进度，程序员只关心自己的开发进度。分析：这是一种“官僚”的想法。实际上程序员作为团队中的一 员，他不仅仅是在打一份工，更重要的是在参与一件“作品”的创作。在体味工作的辛苦的同时，程序员更重要的是要享受创作的快感。项目经理不应该漠视程序员 对“成就感”的追求，应该向每一个人详细描述最终“ 作品”将会如何美妙和令人兴奋，并且在到达最终目标的路上设立一系列的里程碑。每当项目整体推进到一个里程碑的时候，项目经理应该把这个消息告诉每一位项 目成员。实际上，这不仅仅可以让所有的项目成员享受到阶段胜利的喜悦，还可以激发大家更大的工作热情，提高工作效率。

　　经理的许多工作都是通过向下属员工发布命令来完成的，离开了发布命令，经理将要么无所作为，要么事必躬亲，而这两 种情况都是有背经理职责的。

　　发布命令也是经理经常忽视的问题，是经理能力的一个薄弱的环节，它甚至阻碍了经理的成长，减弱了经理的影响力。

　　在管理咨询界流行着这样一句话，“当你新到一个陌生的企业，你不用问老板就可以知道哪个员工干的最好，那个最忙碌 的、经常在老板面前晃来晃去的人就是老板眼里干的最好的员工”。

　　这个逻辑很简单，老板喜欢把事情交给让自己放心的人去干，这样事情办得又好自己又省心，如此长期下去，那个最令老 板放心的员工就是干得最多的员工，也是老板眼里干的最好的员工。

　　这其实也是一些经理发布命令的逻辑，不管要做的是什么事情，也不管员工的职责是什么，只要这个员工让自己放心，就 肯把事情交给他办，反之，那些不太令自己放心的员工则很少获得办事情尤其办大事情的机会。

　　所以在一些团队或组织里，有的员工很忙，有的员工很闲，工作任务分配不均衡，职责权限不匹配的现象很严重，造成了 员工之间能力发展的不均衡，为未来经理合理配置人力资源造成了一定的麻烦，顶梁柱也有倒塌的时候不是？

　　经理经常发布一些未经思考的命令，有的命令让员工走错了方向做错了事，有的命令让员工不知所云，茫然无措。

　　发布命令正在成为经理职业发展的一个瓶颈。

　　经理发布命令中的常见问题

　　1.没有找对人。这种情况的经理有两种，一种就是我们前面所讲的喜欢把事情交 给令自己放心的员工的经理，这种经理不管事情的性质、内容，也不管到底应该有哪些部门哪些人负责，全部让自己可以放心的人负责。另外一种就是特别忙碌的经 理，这种经理在 忙 起来的时候喜欢抓瞎，不管那件事情应该谁负责，也不管那个人能不能做得了那件事，只是抓来就用。这就是没有找对人。

　　2.没有说对事。有的经理在没有听明白或者没有看明白所要办理事情的内容之前 就匆匆找到下属简单交代两句，然后再匆匆从下属眼前消失。这种发表命令很容易导致经理自己都没有弄明白自己对员工的要求，员工当然更不能明白，导致了员工 办事的效率下降 ， 有时为了一件事情要来回跑好几趟，员工不但心情受到了影响，对经理的信心也会逐渐地下降。 

　　3.没有说清楚。有的经理在发布命令的时候喜欢言简意赅，多说一个字都不愿意 。使得员工不知道该找谁，该怎么办，该在什么时候办完，办到什么程度才算满意，这一系列的问题，经理都没有交代清楚，员工怎么能高效地完成，这又影响了员 工的士气。再者 ， 由于经理的权威，员工尽管没有听清楚，也不敢去问，没有办法的情况下只能拖延，最后不但事情没有办好，员工的拖拉作风却逐渐养成了。

　　员工发布命令不明确的原因很多，主要有如下几个方面：

　　1.个人喜好。有的经理喜欢根据个人的喜好来确定命令的发布，喜欢谁就让谁办 ，完全不考虑那件事情是不是该由那个人办，缺乏办事的原则和管理的科学性。

　　2.责任心。一个负责的经理一定会慎重对待自己面对的每一件事，每一个人，他 会把自己的事情安排得有井有条，把事情的要求说深说透，让员工工作有方向，努力有成果。但是不负责的经理却很少能这么认真地对待，他们只是希望把找到自己 的人和事尽快地 推 给他们，责成下属办理。这种不负责任的态度导致了一些命令发布的仓促、不明确。

　　3.工作忙。由于缺乏规划、没有授权等原因，经理总是很忙，经常埋在案头，处 理大量的事务性工作。工作忙处理的速度就要快，所以经理总是快速地把一些命令发布出去，根本无暇估计是不是找对了人、说对了事，当然更没有时间去清楚地表达，导致了命令 无 效。

　　4.不会。所有的经理都懂管理吗？也许都会。那么，所有的经理都会管理吗？这 个问题恐怕都打一个问号。我们有的经理正在面临着科学化管理的挑战，也正在受到管理混乱的困扰，他们中有的人真的需要加强学习。

　　经理如何发布命令？

　　1.让工作的节奏慢下来。以前我们经常提倡经理别坐下来，赶快去行动，现在我 们应该换一个角度，换一种思路，经理工作节奏别太快了，先慢下来，想清楚了再做，这样才能更好地保证经理的工作效率。

　　2.明确命令的要求。当经理想要做一件事情或者接到一个任务需要交代下属办理 时，首先要想清楚自己想要做的事情，这件事情的要求是什么，什么时间完成。

　　3.明确办事的员工。根据员工的岗位职责，结合所需办理的事情，确定需要接受 命令的员工。

　　4.传达命令。将所要办理的事情明确清晰地传达给当职员工，告诉员工这是一件 什么事情，需要办到什么程度，截止的日期是什么，让员工清楚每一个环节。尤其是截止时间，因为一旦员工不明确截止时间，他就不知道该如何安排工作的进度，也就会影响工作 完 成的效果，影响员工的工作效率。

　　5.做好控制。命令发出之后，就等于你的行事例上多了一件事情，经理需要根据 自己的命令确定任务的验收时间，做好员工工作的控制，在截止时间结束之前与员工确认任务的完成情况。

　　发布命令是有学问的，是需要经理耐心研究仔细运用的，经理应对之进行有效的研究和使用，使之成为经理成功实现自我 的权仗。

1．1　　　 定义

　　工作分解结构是将项目的可交付物和活动按照其内在的逻辑结构或实施的过程顺序进行逐层分解而形成的结构图。

从这个定义，我们可以分析出如下的内容：

　　Ø 分解的可选角度有两个：按可交付物分解和按活动分解。按可交付物分解而得到的产出物用于进行项目范围确认，以及建立项目验收标准；按活动分解而得到的产出 物用于项目时间管理部分的活动定义。

　　Ø　　　　　　 工作分解结构是一张树型结构的逻辑示意图。

　　Ø 通过对项目范围说明书的分解，会得到不同详细程度的工作分解结构。

工作分解结构是一种工作分解技术，是项目在不同细节水平上的概述或描述，它将为项目范围确认和项目活动定义提供支持。

　　1．2 工作分解结构的意义

　　化繁为简，将项目分解到易于管理和控制的程度，并为后续的工作，包括：项目范围确认，项目进度控制，项目质量控制， 项目成本控制，人员的安排等方面提供有力的支持。这就是制定工作分解结构的目的。如下图所示：

　　2．　　　　　　　　　　　 制定工作分解结构

　　2．1 工作包

　　工作包 是进行工作分解结构的最终产物。它是一系列相关工作或任务的集合，它位于工作分解结构的最底层，是易于被项目组成员所掌控的事物。它同时也是进行后续项目 管理工作的基础和依据，所有的进度计划，质量管理计划，成本计划，人员安排都是以它为基础而进行的，它是开展项目管理的最小单位。

　　在进 行工作结构分解，产生一系列工作包的时候，我们可以参考如下原则：

　　Ø 工作包是独立地可交付单元，它应该是明确的，唯一的。

　　Ø　　　　　　 工作包中的工作任务应该能够明确地落实到某个组织或个人。

Ø　　　　　　 工作包的生命周期应该是最短的。

　　Ø　　　　　　 明确工作包与其他工作包的关系。

　　Ø 工作包能够确定实际的成本预算，人力和资源的需求。

　　Ø 工作包中的大多数工作任务对项目组中相同类型的人员应该具有适应性。

　　2．2　关键要素

在上一节里介绍了在产生工作包时应该注意或参照的一些原则，也就是说，这些原在在生产工作包的时候具有一定的参考意义。那么，当一系列工作包被分解出来以 后，项目组应该如何处理这些工作包，或者说，项目组拿到这些工作包以后，接下来需要做哪些工作呢？

　　建议如下：

　　Ø 内容或活动过程描述。根据项目范围说明书，对每一个工作包进行描述，表明工作包的性质。

　　Ø 分配责任人。指明相关的组织和个人对工作包的任务负责。即：由他们来完成这个工作包的任务。

　　Ø 确定工作包的生命周期。即：确定工作包的开始时间和结束时间。

　　Ø 依据工作包制定相关计划或分配必须的资源。如：为每个工作包制定进度计划，成本估计，质量管理计划等。

　　2．3 工作分解结构与里程碑

在工作分解结构的单元（工作包，或者是工作分解结构的某个中间层）完成的时候，都会产出一系列的可交付成果。同时，根据项目的实际情况，项目组可以将这 个工作单元与一个里程碑关联起来。

里程碑标志着某个成果或者阶段工作的完成。通常，里程碑是和可交付成果紧密联系在一起的。在达到里程碑的时候，项目组成员可以对项目进行总结，反思。如果 发现问题，可以采取必要的补救措施。里程碑的存在能够使项目组的目标比较专一，与项目的主要目标和可交付成果相比，里程碑的实现更加容易和可控，能够减少 项目风险。

　　 根据工作分解结构，在项目运行过程中的某个时间点社顶里程碑是有意义的。

　　2．4 制定工作分解结构的思维过程

　　2．4．1 概述

在2。4这一节里，将会详细的讲述如何指定工作分解结构这一问题。首先，让我们先仔细阅读下面的阐述。

在项目管理方面，我们已经拥有了前人为我们总结的一系列的理论、知识、技巧。然后，项目管理是一门重视实践的学科，项目经理是干出来的。仅仅熟读几本项目 管理方面的书是不会成为一名合格的项目经理的。合格的项目经理是理论结合实际，长期锻炼的产物。

因此，同样道理，在制定工作分解结构方面，我们没有一种一试百灵的方法，没有一种让我们可以直接套用的模式、结构或者公式。没有一种这样的东西，让我们一 但得到它就能简单地制作出工作分解结构。

我们拥有的是前人给我们总结的一些理论，知识，技能和一些原则。然后，这些东西还不是足够地。这些理论，知识，技巧还需要结合项目的实际情况，经过仔细地 思考，才能创造出满意的工作分解结构。

因此，可以这样来说，制作工作分解结构地过程，也就是项目管理人员利用已有的理论，知识，技巧结合项目实际情况进行权衡，取舍，思考的这一个过程。而学会 制作工作分解结构的这一过程，也就是学会如何进行思考的这一个过程。这里重点在于如何思考，如何去分析问题。最终，我们达到的目标就是：形成自己的风格， 形成自己的东西。

　　 其实，我们学习项目管理，也就是在改变我们原来的自发的思维方式，学习作事情的方式、方式而已。

接下来，我们将结合项目管理的方法，理论，知识，技巧和一些原则，从思维的角度来介绍如何制作工作分解结构。这将会设计到思考问题的顺序，看问题的角度， 分析问题所把握的深度，做事情的方式、方法，以及一些常用原则。

　　2．4．2 分解步骤

　　在制作工作分解结构的时候，有 两个输入。他们分别是：

　　Ø 详细地项目范围说明书。我们就是要将范围说明书中所描述地项目目标以分解图形的方式表达出来。它相当于这一工作步骤的原材料。这里的详细范围说明书可能是 某个项目的整体描述，也可能仅仅是一个工作包的描述。

　　Ø 项目范围管理计划。它是一个指南。项目范围管理计划里面列出了项目管理者的一些规范，要求，在制作工作分解结构的时候，项目组成员需要遵循它。

首先，让我们来看这样一个流程图：

接下来，根据管理者所站的层次，决定分解的深度。确定分解的层次深度这一知识将在2。4。4节进行详细讲述；然后，就开始进行项目目标的分解。关于分解的 基准和角度，将在2。4。3节讲述；分解的方法，将在2。4。5节讲述；最后，得到了本次分解工作所需要的工作分解结构图，并依据工作包进行职责分配，以 及进行相关的过程控制。

在进行职责分配以后，接手这个工作包的组织或个人，根据项目的实际情况，可以对这个工作包继续进行分解，直到得到能够掌控的工作包。如图中的循环部分。

2．4．3 分解基准

　　在这一节里，我们讲述这样一个问题，棉队详细的项目范围说明书，我们应该如何下手，从什么角度来看问题，按什么 样的标准来进行分解。

　　对于一个项目系统来说，存在多种分解方式，常用的分解方式描述如下：

　　Ø 按照项目的组织结构进行分解。

　　Ø　　　　　　 按照项目范围的构成进行分解。即：根据一级交付物，二级交付物…进行分解。

Ø　　　　　　 按照项目的实施阶段进行分解。

在进行项目目标分解的时候，需要将项目的进程，范围，组织这三种结构形式综合考虑。实际上，在创建工作分解结构的时候，就是这三种方式的混合使用。比如： 工作分解结构的第一层是按组织结构进行分解，而一层可能就是按照项目的范围今昔功能分解。具体情况看参照下图：

　　图片看不清楚？请点击这里查看原图（大图）。

在制定工作分解结构的时候，应采用何种方式进行分解，需要结合项目的实际情况而定。而在决定这些事情的时候，我们可以参考如下要素：

　　Ø 采用哪一种方式会更有意义？

　　Ø　　　　　　 如何将生成的工作包分配给组织或个人？

　　Ø 如何去实现这个工作包？

　　 也就是说，我们采用了一种分解标准分解出工作包以后，这个工作包是可以被分配地，并且是能够被完成地。

2．4．4 分解的详细程度

　　在这一节里，我们主要讨论的是一个“度”的问题。在建立工作分解结构的时候，需要将项目的目标分解到什么 程度才算合理呢？

　　实际上，在建立一个工作分解结构的时候，并没有一个标准的模式，也不存在一个标准的详细程度，一切都需要根据项目的实 际情况而定。

　　首先，对工作分解结构的详细程度起到影响作用的第一个因素是：管理者所站的高度。项目的工作分解结构，尤其是大型项目，它 不是由一个项目管理人员来制定地，它是由不同层次的管理人员相互协作，共同制定地。制定这个工作分解结构的具体流程如下图：

　　接下来，为 了更加详细地说明这个问题，我们来看下面的表格：

　　由上，我们可以看出， 管理者所站的层次越高，那么由他所分解出来的工作分解结构的详细程度就越低；反之，管理者所站的层次越低，那么由他所分解出来的工作分解结构的详细程度就 越高。因为，越接近底层，就越接近具体实施，就要求分解的程序更详细。

　　其次，对工作分解结构的详细程度起到影响的二个因素是：分解出来 的工作包是否可控。如果可控，则实现之；如果不可控，则继续分解，直到可以被项目组成员完全掌握。

　　需要关注的是，分解出来的工作包的大 小不能太大，也不能太小。这里有一个原则：8-80原则。也就是说，这个工作包最少需要8个小时完成，最多完成时间不要超过80个小时。在计量项目时间进 度的时候，可以以天为单位来计算，而一些大的项目则以周为单位。

　　另外，在整个制作工作分解结构的过程中，需要生成一些配套文件，这些配 套文件需要和工作分解结构一起使用。这些文件称为：工作分解结构词汇表。

　　工作分解结构词汇表的主要内容有：

　　Ø 工作说明，负责人。

　　Ø　　　　　　 进度里程碑清单。

　　Ø 质量要求，计划活动，资源和费用估算等。

　　Ø　　　　　　 其他。

　　2．4．5 分解的方法

　　在进行工 作结构分解的时候，有如下四种方法可以使用。

　　Ø　　　　　　 自上而下法。即：先从总体考虑，然后逐层分解，知道底层。

Ø　　　　　　 自下而上法。即：先从底层考虑，然后不断归纳。

　　Ø　　　　　　 两者混合。对前面两种方法结合使用。

Ø　　　　　　 模板法。在组织过程资产中寻找相关类型的模板，然后使用。

　　2．4．6 分解的基本原则

在制定工作分解结构的时候，存在一些需要主要的事项或原则，如下：

　　Ø　　　　　　 一项任务只能在工作分解结构中出现一次。

Ø　　　　　　 某一级别的工作任务应该是下一级别的工作任务之和。

　　Ø　　　　　　 工作分解结构的底层应该支持计划和控制。

Ø　　　　　　 工作分解结构中的每一项任务必须有人负责，且只有一个人负责，尽管实际有多人参与。

　　Ø 尽量使项目团队中的成员都参与工作分解结构的制定。

　　Ø　　　　　　 工作分解结构并非一成不变，项目范围的变更会对它产生影响。

http://tech.ddvip.com/2009-05/1242193732118884.html

SCM学习第二周，了解到软件工程的危机---------大量的代码无法统一，没有统一的 管理 变更带来的大量的问题（费时 成本高质量差），随着软件的发展，代码在 失控，这时配置管理开始挽救整个软件业。

    WHAT-----早在七十年代初期加利福利亚大学的Leon Presser教授就撰写了一篇论文，提出控制变更和配置的概念，之后在1975年，他成立了一家名为Soft Tool的公司，开发了自己的配置管理工 具：CCC，这也是最早的配置管理工具之一。之后，随着软件开发规模的逐渐增大，越来越多的公司和团队意识到了 软件配置管理的重要性，而相应的软件配置管理工具也如雨后春笋一般，纷纷涌现，比较有代表性的有：Marc Rocking的SCCS(Source Code ControlSystem)和Walter Itchy的RCS(RevisionControl System)，这两种工具对日后的配置管理工具的发展做出了重大的贡献，目前绝大多数广泛使用的配置管理工具基本上都是基于这两者的设计思想和体系架构。什 么是软件配置管理呢？软件配置管理有多种定义，在1986年出版的Wayne Babyis《SoftwareConfigurationManagement:Coordinating for Team Productivity》一书中把软件配置管理描述为"对软件开发组所建立的软件的修改 进行标识、组织和控制的艺术，其目标是减少错误，提高生产力"。这个定义比较简单，而在1993年出版的Steve McConnell的《Code Complete》一书中，从另一个角度对软件配置管理进行了定义："配置管理能够系统地处理变更，从 而使得软件系统可以随时保持其完整性。配置管理又可称为'变更控制'，可以用来评估提出的变更请求， 跟踪变更，并保存系统在不同时间的状态。" 软件配置管理是一套规范、高效的软件开发基础结构。作为管理软件开发过程 有效的方法，SCM早已被发达国家软件产业的发展和实践所证明。SCM可以系统地管理软件系统中的多重 版本；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。SCM对开发过程进行有效地管理和控制，完整、明确地1.记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会2.保护宝贵的代码资源，积累软件财 富，提高软件重用率，加快投资回报。SCM是通往ISO9000和SEI CMM标准的一块基石。在软件开发团队 中，正确地采用、实施软件配置管理系统，必将提高生产力，增强对整个项目的控制，改善软件产品的质量，从容面对快速面市和产品质量的双重压力。软件配置管 理系统的实施，一般来讲要考虑两个方面的因素：流程和工具。流程和工具是相辅相成的，流程起决定性作用，它确定了管理的规则和方法，工具用来将变更存储在 一个中央存储库中，可以重现任一时期的历史版本，一个好的工具可以提高效率，是贯彻实施流程的必要手段。因此，在一个开发团队中，实施配置管理流程比采用 配置管理工具更重要，我们需要充分考虑，制定出适合自己企业的配置管理流程，该流程必须与公司的开发规范、质量系统等完全结合。

      在软件开发中，变更是不可避免的。从某种角度上讲，软件开发过程就是一个变更的过程。有些变更是有益的，是具有创造性的，但是，也有些变更是有害的，导致 混乱的。正像James Bach 总结的那样：我们为变更所困扰，因为代码中的一个极小的混乱可能带来产品的大的故障，但是，他也能够修复大的故障或启用奇妙的新能力。我们为变更所困扰， 因为某个喜欢恶作剧的单个开发者可能破坏掉项目，但是，一些奇妙的思想也源自那些喜欢恶作剧的人员。
因此，如何管理这些变更是一个软件开发能否成 功的关键。简言之，
软件配置管理就是管理变更的过程，它贯穿着几乎软件的整个生命周
期。成功的配置管理系统可以提高产品的质量、项目开发 效率，而且最大限度的减少对个别“英雄”式人员的依赖。
     软件开发过程的输出信息可以分为三个主要的类型：(1)计算机程序（源代码、中间代码和可执行程序），（2）描述计算机程序的文档（针对技术开发者和用 户），（3）数据（包含在程序内部或在程序的外部）。这些项包含了所有的在软件过程中产生的信息，总称为软件配置。该集合中每一个元素称为该软件产品软件 配置中的一个配置项（CI,Configuration Item）。尽管配置管理（Configuration Management ）这个概念被提出有几十年了，但是，业内还没有一个全面而权威的定义。Configuration 的
意思是“使成形”，它来源于拉丁语的 com-（表示“与”或者“一起”）和figurate (形成)。它还有一个意思是“组成部件或元素的相对排列”。因此，配置管理（Configuration Management ）指的是管理组成部件或者元素的相对排列。配置管理的概念来自于硬件领域，美国国防部最早使用了配置管理的概念。
我们知道一架飞机的构成非常复 杂，比如机头、机身、机翼和机尾
等。不同型号飞机的各个部分是不能随便组装的。因此，我们只有把相匹配的部件组装在一起，才能构成了一个功能完备 的飞机整体。随着技术的提高，各个部件可能还要进行功能改善，我们还要使得不同版本的部件能够正确无误组合在一起。
     准确地说：配置管理是对产品进行标识、存储和控制，以维护其完整性、可追溯性以及正确性的学科。

    WHY----在团队开发的模式中，软件开发管理就显得更加重要，其管 理的好坏将直接影响到软件产品的质量。如果缺乏对软件开发的统一管理，势必造成以下问题的出现：
● 由于开发经费及开发时间的限制，不可能一次开发就解决
所有问题，许多问题有待维护阶段解决，因此带来的是软件产品的不断
升级，而维护和升 级所必需的文档往往非常混乱；
● 开发商开发过程缺乏规范化的管理，即使有源程序文档也由
于说明不详细而不能对产品进行进一步的功能扩 充，用户不得不再投入大量的经费去开发新产品，浪费大量的人力、物力和时间；
● 在软件的团队式开发中，人员流动在所难免，如管理不善，
有 些人员的流动将对开发产生致命的影响。特别是软件开发管理人员或核心成员的流失，有可能造成无法确定软件产品中各模块所处的状态及阶段， 使软件产品的版本出现混乱，甚至可能泄漏公司的核心机密；
● 管理不善致使没经测试的软件加入到产品中，不但影响产品
的质量，有时还会导致致命的错误，造成不可挽回的损失；
PDF 文件使用 "pdfFactory Pro" 试用版本创建
● 用户与开发商没有有效的沟通手段，用户投入了开发费用
后，得到的是有关可执行程序以及一堆杂乱无章的文档，即使是较好的文档，对不熟悉开 发过程的专业人员来说也无从下手，更谈不上日后的维护和升级，用户的利益无法保证；
● 软件生产达不到规模化，无法生产出软件企业内部的软件标准构件仓库，使应用软件产品总处于一种低水平、重复开发的状态，不但时间得不到保证，而且 成本也无法降低，使产品没有市场竞争力。这些问题在实际开发中表现为，项目组成员沟通困难，软件重用率低下，开发人员各自为政，代码冗余度高，文档不健全 等；造成的结果是：数据丢失，开发周期漫长，产品可靠性差，质量低劣，软件维护困难，用户抱怨使用不便，项目风险增加等。
    HOW----配置标识就是识别产品的结构、产品的构件及其类型，为其分配唯一 的标识符，也就是说，每一个配置项要有一个唯一标识。一般说来，标识包括两个方面：一是文件名，二是版本，可用如下一个二元组来标识：<文件名，版 本>。每个项目首先要确定一套命名规则，例如，采用“系统.子系统.模块.文件”的方式，</videoConference /audio/compressing /main.c , 2.1>就是一个唯一.标识。
  版本控制
版本控制就是对在软件开发过程中所创建的配置对象的不同版本
进行管理， 保证任何时候都能取到正确的版本以及版本的组合。
软件配置管理基线管理 变更请求管理 发布管理 构建管理
配置标识 版本控制 变更控制 配置状态统配置审核当前，这方面典型的工具有如VSS 和CVS。
 变更控制
在软件开发过程，要产生许多变更，比如，配置项、配置、基线、
构建的版本、发布版本等。对于所有的 变更，都要有一个控制机制，以保证所有变更都是可控的、可跟踪的、可重现的。对变更进行控制的机构称为变更控制委员会（Change Control Board，简称CCB）。变更控制委员会要定期召开会议，对近期所产生的变更请求进行分析、整理，并做出决定。而且要遵循一定的变更机制。
下面 是一个典型的变更机制：
接受 拒绝提交变更请求管理变更请求管理就是对变更请求（Change Request，简称CR）进行分类、追踪和管理的过程来实现的。
变更的起源有两种：功能变更和缺陷修补（Bug-Fix）。功能变更
是 为了增加或者删除某些功能。缺陷修补则是对已存在的缺陷进行修
修改测试或验证对变更请求的有效管理可以提高产品管理的透明度，经理可以清楚的知道 当前产品的进展情况，比如有多少个新产生的CR，已经解决了多少CR 等等，有利于经理做出正确的决策。
基线管理
基线是指经过正式评审和批准，可作为下一步工作的基准的一个配
置。软 件开发过程中，无论是需求分析、设计、测试都需要在完成时建立基线，以作为下一步工作的基础。通过基线管理可以使用户能够通过对 适当版本的选择来组成特定属性（配置）的软件系统，这种灵活的“组装”策略使得配置管理系统像搭积木似的使用已有的积（版本）组装成各种各样、不同功能的 模型。基线的变更需要一个严格的流程，需要提出申请，经过审批，然后才能进行。
构建管理
在做构建时，我们需要首先取出正确的配置，然后再做构建。我们
可以利用基线，可以取出某 个基线的所有配置项，也可以利用配置管理系统的构建功能直接在工作空间内做构建。构建管理需要配置管理工具的支持。
发布管理
软件产品的每个版本都是一组配置项（源代码、文 档、数据）的集
合。举个例子来说，我们要发布软件的32.6 版本，那么我们就要把源代码、文档、数据中所有应该包含到这个版本中的正确 配置项检出。所以如何管理每个版本中包含哪些配置项是非常重要的。
状态报告状态报告要回答所谓4W 的问题：
What：发生了什 么事？
Who：谁做的此事？
When：此事是什么时候发生的？
Why：为什么做此事？
状态报告要能够报告所有配置项以及 变更请求的状态，通过量化的
数据和报表反映项目开发进度的状态。
配置审核
配置审核要审查整个配置管理过程是否符合规范，配置项是否与需
求一致，记录正确，配置的组成是否具 有一致性等等。比如，需求分析文档提交后，需要由一个由相关人组成的小组进行正式评审，只有通过了评审才能基线化。对于源代码也一样，一般说来，每行代码 都要进行评审（Review），只有通过评审才能交由测试人员进行测试。
实施配置管理的好处  我们知道软件有三个要素：时间、预算和质量。一个成功 的软件就是要在限定的时间内，不超过预算，交付符合质量要求的产品。真正实施配置管理后，我们会对产品的开发过程进行有效的控制，可以加快开发进度，降低 开发成本，保证产品的质量。
     产品经理可以得到什么好处呢？
准确掌握项目的开发进度。配置管理系统可以提供详尽的状态报告，例如 当前系统有多少个Bug，所有Bug 的状态如何？已经解决了多少Bug？了解项目组成员的工作负荷、工作效率以及工作质量。例如，我们可以知道当前分配给每个成员的工作量，每个成员已完成的 工作量，每个成员未通过正式评审的工作比例等等。减少人员流动所带来的影响。每个成员的所有变更，包括文档、代码的增删都是可追踪的，而且对于变更的原 因、描述也都有记录。样，一旦成员离开，其它成员就可以在最短的时间里接手。有效提高过程管理，配置管理产生的许多数据可作为管理者度量项目的依据。

    WHAT-----早在七十年代初期加利福利亚大学的Leon Presser教授就撰写了一篇论文，提出控制变更和配置的概念，之后在1975年，他成立了一家名为Soft Tool的公司，开发了自己的配置管理工 具：CCC，这也是最早的配置管理工具之一。之后，随着软件开发规模的逐渐增大，越来越多的公司和团队意识到了 软件配置管理的重要性，而相应的软件配置管理工具也如雨后春笋一般，纷纷涌现，比较有代表性的有：Marc Rocking的SCCS(Source Code ControlSystem)和Walter Itchy的RCS(RevisionControl System)，这两种工具对日后的配置管理工具的发展做出了重大的贡献，目前绝大多数广泛使用的配置管理工具基本上都是基于这两者的设计思想和体系架构。什 么是软件配置管理呢？软件配置管理有多种定义，在1986年出版的Wayne Babyis《SoftwareConfigurationManagement:Coordinating for Team Productivity》一书中把软件配置管理描述为"对软件开发组所建立的软件的修改 进行标识、组织和控制的艺术，其目标是减少错误，提高生产力"。这个定义比较简单，而在1993年出版的Steve McConnell的《Code Complete》一书中，从另一个角度对软件配置管理进行了定义："配置管理能够系统地处理变更，从 而使得软件系统可以随时保持其完整性。配置管理又可称为'变更控制'，可以用来评估提出的变更请求， 跟踪变更，并保存系统在不同时间的状态。" 软件配置管理是一套规范、高效的软件开发基础结构。作为管理软件开发过程 有效的方法，SCM早已被发达国家软件产业的发展和实践所证明。SCM可以系统地管理软件系统中的多重 版本；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。SCM对开发过程进行有效地管理和控 制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财 富，提高软件重用率，加快投资回报。SCM是通往ISO9000和SEI CMM标准的一块基石。在软件开发团队 中，正确地采用、实施软件配置管理系统，必将提高生产力，增强对整个项目的控制，改善软件产品的质量，从容面对快速面市和产品质量的双重压力。软件配置管 理系统的实施，一般来讲要考虑两个方面的因素：流程和工具。流程和工具是相辅相成的，流程起决定性作用，它确定了管理的规则和方法，工具用来将变更存储在 一个中央存储库中，可以重现任一时期的历史版本，一个好的工具可以提高效率，是贯彻实施流程的必要手段。因此，在一个开发团队中，实施配置管理流程比采用 配置管理工具更重要，我们需要充分考虑，制定出适合自己企业的配置管理流程，该流程必须与公司的开发规范、质量系统等完全结合。

      在软件开发中，变更是不可避免的。从某种角度上讲，软件开发过程就是一个变更的过程。有些变更是有益的，是具有创造性的，但是，也有些变更是有害的，导致 混乱的。正像James Bach 总结的那样：我们为变更所困扰，因为代码中的一个极小的混乱可能带来产品的大的故障，但是，他也能够修复大的故障或启用奇妙的新能力。我们为变更所困扰， 因为某个喜欢恶作剧的单个开发者可能破坏掉项目，但是，一些奇妙的思想也源自那些喜欢恶作剧的人员。
因此，如何管理这些变更是一个软件开发能否成 功的关键。简言之，
软件配置管理就是管理变更的过程，它贯穿着几乎软件的整个生命周
期。成功的配置管理系统可以提高产品的质量、项目开发 效率，而且最大限度的减少对个别“英雄”式人员的依赖。
     软件开发过程的输出信息可以分为三个主要的类型：(1)计算机程序（源代码、中间代码和可执行程序），（2）描述计算机程序的文档（针对技术开发者和用 户），（3）数据（包含在程序内部或在程序的外部）。这些项包含了所有的在软件过程中产生的信息，总称为软件配置。该集合中每一个元素称为该软件产品软件 配置中的一个配置项（CI,Configuration Item）。尽管配置管理（Configuration Management ）这个概念被提出有几十年了，但是，业内还没有一个全面而权威的定义。Configuration 的
意思是“使成形”，它来源于拉丁语的 com-（表示“与”或者“一起”）和figurate (形成)。它还有一个意思是“组成部件或元素的相对排列”。因此，配置管理（Configuration Management ）指的是管理组成部件或者元素的相对排列。配置管理的概念来自于硬件领域，美国国防部最早使用了配置管理的概念。
我们知道一架飞机的构成非常复 杂，比如机头、机身、机翼和机尾
等。不同型号飞机的各个部分是不能随便组装的。因此，我们只有把相匹配的部件组装在一起，才能构成了一个功能完备 的飞机整体。随着技术的提高，各个部件可能还要进行功能改善，我们还要使得不同版本的部件能够正确无误组合在一起。
     准确地说：配置管理是对产品进行标识、存储和控制，以维护其完整性、可追溯性以及正确性的学科。

    WHY----在团队开发的模式中，软件开发管理就显得更加重要，其管 理的好坏将直接影响到软件产品的质量。如果缺乏对软件开发的统一管理，势必造成以下问题的出现：
● 由于开发经费及开发时间的限制，不可能一次开发就解决
所有问题，许多问题有待维护阶段解决，因此带来的是软件产品的不断
升级，而维护和升 级所必需的文档往往非常混乱；
● 开发商开发过程缺乏规范化的管理，即使有源程序文档也由
于说明不详细而不能对产品进行进一步的功能扩 充，用户不得不再投入
大量的经费去开发新产品，浪费大量的人力、物力和时间；
● 在软件的团队式开发中，人员流动在所难免，如管理不善，
有 些人员的流动将对开发产生致命的影响。特别是软件开发管理人员或
核心成员的流失，有可能造成无法确定软件产品中各模块所处的状态及
阶段， 使软件产品的版本出现混乱，甚至可能泄漏公司的核心机密；
● 管理不善致使没经测试的软件加入到产品中，不但影响产品
的质量，有时还会导 致致命的错误，造成不可挽回的损失；
PDF 文件使用 "pdfFactory Pro" 试用版本创建
● 用户与开发商没有有效的沟通手段，用户投入了开发费用
后，得到的是有关可执行程序以及一堆杂乱无章的文档，即使是较好的
文档，对不熟悉开 发过程的专业人员来说也无从下手，更谈不上日后的
维护和升级，用户的利益无法保证；
● 软件生产达不到规模化，无法生产出软件企业内部的软件
标准构件仓库，使应用软件产品总处于一种低水平、重复开发的状态，不但时间得不到保证，而且 成本也无法降低，使产品没有市场竞争力。这些问题在实际开发中表现为，项目组成员沟通困难，软件重用率低下，开发人员各自为政，代码冗余度高，文档不健全 等；造成的结果是：数据丢失，开发周期漫长，产品可靠性差，质量低劣，软件维护困难，用户抱怨使用不便，项目风险增加等。
    HOW----配置标识就是识别产品的结构、产品的构件及其类型，为其分配唯一 的标识符，也就是说，每一个配置项要有一个唯一标识。一般说来，标识包括两个方面：一是文件名，二是版本，可用如下一个二元组来标识：<文件名，版 本>。每个项目首先要确定一套命名规则，例如，采用“系统.子系统.模块.文件”的方式，</videoConference /audio/compressing /main.c , 2.1>就是一个唯一.标识。
  版本控制
版本控制就是对在软件开发过程中所创建的配置对象的不同版本
进行管理， 保证任何时候都能取到正确的版本以及版本的组合。
软件配置管理基线管理 变更请求管理 发布管理 构建管理
配置标识 版本控制 变更控制 配置状态统配置审核当前，这方面典型的工具有如VSS 和CVS。
 变更控制
在软件开发过程，要产生许多变更，比如，配置项、配置、基线、
构建的版本、发布版本等。对于所有的 变更，都要有一个控制机制，以保证所有变更都是可控的、可跟踪的、可重现的。对变更进行控制的机构称为变更控制委员会（Change Control Board，简称CCB）。变更控制委员会要定期召开会议，对近期所产生的变更请求进行分析、整理，并做出决定。而且要遵循一定的变更机制。
下面 是一个典型的变更机制：
接受 拒绝提交变更请求管理变更请求管理就是对变更请求（Change Request，简称CR）进行分类、追踪和管理的过程来实现的。
变更的起源有两种：功能变更和缺陷修补（Bug-Fix）。功能变更
是 为了增加或者删除某些功能。缺陷修补则是对已存在的缺陷进行修
修改测试或验证对变更请求的有效管理可以提高产品管理的透明度，经理可以清楚的知道 当前产品的进展情况，比如有多少个新产生的CR，已经解决了多少CR 等等，有利于经理做出正确的决策。
基线管理
基线是指经过正式评审和批准，可作为下一步工作的基准的一个配
置。软 件开发过程中，无论是需求分析、设计、测试都需要在完成时建立基线，以作为下一步工作的基础。通过基线管理可以使用户能够通过对 适当版本的选择来组成特定属性（配置）的软件系统，这种灵活的“组装”策略使得配置管理系统像搭积木似的使用已有的积（版本）组装成各种各样、不同功能的 模型。基线的变更需要一个严格的流程，需要提出申请，经过审批，然后才能进行。
构建管理
在做构建时，我们需要首先取出正确的配置，然后再做构建。我们
可以利用基线，可以取出某 个基线的所有配置项，也可以利用配置管理系统的构建功能直接在工作空间内做构建。构建管理需要配置管理工具的支持。
发布管理
软件产品的每个版本都是一组配置项（源代码、文 档、数据）的集
合。举个例子来说，我们要发布软件的32.6 版本，那么我们就要把源
代码、文档、数据中所有应该包含到这个版本中的正确 配置项检出。
所以如何管理每个版本中包含哪些配置项是非常重要的。
状态报告状态报告要回答所谓4W 的问题：
What：发生了什 么事？
Who：谁做的此事？
When：此事是什么时候发生的？
Why：为什么做此事？
状态报告要能够报告所有配置项以及 变更请求的状态，通过量化的
数据和报表反映项目开发进度的状态。
配置审核
配置审核要审查整个配置管理过程是否符合规范，配置项是否与需
求一致，记录正确，配置的组成是否具 有一致性等等。比如，需求分析文档提交后，需要由一个由相关人组成的小组进行正式评审，只有通过了评审才能基线化。对于源代码也一样，一般说来，每行代码 都要进行评审（Review），只有通过评审才能交由测试人员进行测试。
实施配置管理的好处我们知道软件有三个要素：时间、预算和质量。一个成功 的软件就是要在限定的时间内，不超过预算，交付符合质量要求的产品。真正实施配置管理后，我们会对产品的开发过程进行有效的控制，可以加快开发进度，降低 开发成本，保证产品的质量。
     产品经理可以得到什么好处呢？
准确掌握项目的开发进度。配置管理系统可以提供详尽的状态报告，例如 当前系统有多少个Bug，所有Bug 的状态如何？已经解决了多少Bug？了解项目组成员的工作负荷、工作效率以及工作质量。例如，我们可以知道当前分配给每个成员的工作量，每个成员已完成的 工作量，每个成员未通过正式评审的工作比例等等。减少人员流动所带来的影响。每个成员的所有变更，包括文档、代码的增删都是可追踪的，而且对于变更的原 因、描述也都有记录。样，一旦成员离开，其它成员就可以在最短的时间里接手。有效提高过程管理，配置管理产生的许多数据可作为管理者度量项目的依据。

1. 一个项目的配置管理工作谈起，

从配置管理工具的选择、

配置管理流程制定、

配置管理库结构的确定，

以及作为配置管理工作的推动者如何推动这项工作

等方面仔细 描述一下本人的做法。

2. 以一个项目的配置管理为主线，

项目是某省电信的一个项目，该项目的工作量大约是16人年，项目周期约为1年。

大部分（90%以上）的开发工作在前8个月内完成，后期的工作主要由维护人 员进行系统维护和调整。

在8个月的开发时间中，前5个月由开发人员在公司进行开发，根据用户的需求完成设计，确定系统架构并实现整个框架，部分明确的功能 以及公用模块也在这段时间内完成；后3个月的时间部分开发人员在现场，部分开发人员在公司共同完成后期的开发工作。

整个项目采用的开发语言是C++、Java、ASP，涉及的平台包括Solaris和Windows，采用的开发工具包括Visual Studio和Solaris上的CC。此外，整个项目还使用了一些第三方的平台，如IBM的MQ等。

除用户需求之外，公司还对项目组提出了代码复用方面的要求，开发人员在开发过程中必须注意代码的可重用性。

配置管理前期准备工作

在项目正式启动之后，配置管理工作就可以开始了。配置管理工作开始的第一步就是一份配置管理计划。

一般而言，需要在配置管理计划中明确的内容包括：

　　1、配置管理环境------配置管理软硬件资源；

　　2、 配置库结构；

　 　3、 人员、角色以及配置管理规范；

　　4、 基线计划；

　　5、 配置库备份计划；

　　在下文中，我们将 围绕这些内容进行详细描述。

配置管理环境----软硬件环境---软件（配置工具）---硬件硬盘（备份）

配置管理环境包括软硬件环境。具体的资源需求应该根据项目实际情况来确定，一般需要考虑的包括：网络环境、配置管理 服务器的处理能力、空间需求，配置管理软件的选择等。配置管理环境的确定需要综合考虑各个方面的因素，包括我们采用的开发工具，开发方式，开发人员对配置 管理工具的熟悉程度等，其中，开发人员对配置管理工具的认可和熟悉程度常常直接决定配置管理能否正常进行，如果选择了需要开发人员花费比较大的精力去熟悉 的配置管理软件，我们就必须花费大量时间来进行培训；同时，配置管理软件和开发工具的集成程度也是一个必须考虑的因素，根据我们的经验，选择一个和开发环 境集成紧密的配置管理工具至少可以减少20%花费在Check In/Check Out和配置管理人员保持配置库完整上的工作量。

根据我们项目的实际情况，我们有如下一些考虑：

　根据历史经验，一个类似项目的配置库大小约为3G，考虑到备份等操作对空间的需求，至少应该为配置管理库保留10G以上的空间。为了保证配置管理 库的安全，除了相应的备份计划之外，还可以采用了RAID 0＋1的方式为配置数据库提供更好的可用性保证；

　　考虑到在项目的后期有部分 开发人员会在现场进行开发，因此在网络条件上需要提供对远程访问方式的支持；

　　配置管理服务器的选择和配置管理软件的选择相关，考虑到目 前公司有一台闲置的PC服务器，最好能充分利用这台服务器；

　　配置管理软件必须可以以某种方式支持远程访问，而且由于我们的开发平台涉及 Solaris和Windows，配置管理软件要能够支持这两种平台；考虑到开发工具方面，配置管理工具要求能和我们选择的开发工具进行很好的集成；

　 　项目组的开发人员缺乏使用配置管理工具的经验，有将约30%的开发人员使用过VSS配置管理工具，但仅限于最基础的使用，对VSS的Label等功能没 有概念；结合以上的情况，我们首先考虑配置工具的选择。

　配置管理工具的选择

　　从开发人员具有的配置管理工具使用经验和配置管理工具使用的难易度方面来说，VSS是最好的选择，在现有的 基础上只需要对开发人员进行简单培训；考虑到和开发工具的集成，VSS也是一个不错的选择。不过本项目还要求对远程接入方式的支持，以及对Solaris 平台的支持，VSS肯定是不能满足要求的（VSS通过VPN方式应该是可以实现对远程访问的支持，但VSS的完全共享方式实在是不敢在Internet上 使用）。

　　除VSS外，可以选择的配置管理工具还有CCC Harvest、ClearCase、CVS等，但Harvest和ClearCase使用起来比较复杂，需要一个专门的配置库管理员负责技术支持，还需 要对开发人员进行较多的培训，另外，Harvest和ClearCase价格不菲；CVS在Unix下使用方便，而且是免费的，但其文本方式的操作界面对 于习惯在Windows平台上开发的开发人员来说使用非常不习惯（CVS也有windows下的GUI版本，但经过我们的试用，在操作习惯上和我们目前开 发人员习惯的方式很不相同，较难被接受）。

软硬件环境的选择

　　确定了配置管理工具后，我们使用公司购置的一台Compaq PC Server作为配置管理的硬件环境，该服务器配置如下：

　　CPU：1CPU，P4 2.0G

　　内存：512M DDR

　 　硬盘空间：30G×4

　　网卡：HP G bit网卡一张

　　最终确定的方案是安装该服务器安装Windows 2000 Server操作系统，为了保证配置数据的安全性，我们采用RAID 0＋1方式，总的可用空间在50G左右；另外为了备份的需要，还为服务器配置了一个CDR刻录机。

　软硬件环境的选择

　　确定了配置管理工具后，我们使用公司购置的一台Compaq PC Server作为配置管理的硬件环境，该服务器配置如下：

　　CPU：1CPU，P4 2.0G

　　内存：512M DDR

　 　硬盘空间：30G×4

　　网卡：HP G bit网卡一张

　　最终确定的方案是安装该服务器安装Windows 2000 Server操作系统，为了保证配置数据的安全性，我们采用RAID 0＋1方式，总的可用空间在50G左右；另外为了备份的需要，还为服务器配置了一个CDR刻录机。

　　网络环境的选择

　　公 司已有现成的100M局域网，通过一个交换机和路由器连接至Internet，有一个公网的静态IP；配置管理服务器是内网的一台机器，具有一个内网 IP。为了满足远程访问的需要，我们通过在路由器上设置端口映射，将SOS需要使用的端口映射到配置管理服务器上（缺省情况下，SOS使用8888和 8890两个端口）。

　　在公司的开发人员通过局域网使用VSS访问和操作配置库，在现场的开发人员通过Internet接入对配置库进行 访问和操作。

　　配置库维护和备份计划

　　配置库的维护的备份需要专职的配置库管理员来负责。在整个项目中我们采用的配置库 维护策略是根据Microsoft的Best Practice白皮书建议，包括以下要点：

　　1．保持配置数据库的大小不超过 5G；Microsoft建议，配置库的大小在3－5G比较合适，太大的数据库会极大影响VSS的效率；减小配置库大小的

　　2．每周进行 VSS数据库的分析（Analysis），发现问题及时修正；VSS提供了Analysis和Fix工具，由于不合理的Delete等操作，VSS数据库 有可能会出现一些Interrupt Data之类的问题，通过定期的每周的分析工作，可以极大减少数据库出现问题的风险；

　　3．每日进 行配置库的增量备份，每周进行数据库的完全备份；VSS库的备份可以通过VSS自己的Archive功能或者是操作系统的Backup程序来进行。VSS 的Archive功能对VSS中的文件数据进行压缩并保留VSS的所有状态，但只能对VSS库进行完全备份，不能实现增量备份功能。

　　 Windows2000 Server提供的Backup实用程序可以对文件进行备份，由于VSS库就是以文件形势存在的，因此针对VSS的data目录进行备份也可以完全达到备 份的目的，使用系统备份工具的好处是可以实现增量备份。我们在实际中使用的系统的备份工具，每周五生成的完全备份采用刻录光盘的方式保存，每天的增量备份 数据存放在文件服务器上进行备份。

http://tech.ddvip.com/2009-03/1236143013110314_4.html

1、项目管理知识体系：项目管理知识体系全面的、系统的、结构化的知识框架，有助于项目人员全面理解项目管理，是参与项目并成功
    进行项目管理的基础和前提；
2、个人能力素质：包括个人的自信和自我激励能力、表达能力、时间及压力管理能力、系统思考能力等内容，良好的个人能力素质是项
   目经理及团队成员高效进行各项项目活动的重要保证；
3、人际关系素质：包括如何处理与他人关系的能力，如沟通能力，谈判能力，冲突处理能力等，以确保项目经理及团队成员具备良好的
   与他人保持良好关系，个人具备良好的人际关系素质是项目确保顺利开展的重要保证；
4、通用管理技能：包括一般通用管理的知识和技能，如战略、流程、绩效、组织、财务、营销等，以确保项目经理及团队成员具备良好
   的通用管理技能，个人具备通用管理技能是确保项目有效进展的必要条件；
5、行业项目技能：包括特定行业的项目管理知识和技能，如，IT项目管理、地产项目管理、研发项目管理等；行业项目管理知识和技能
   是项目团队成员进行行业项目管理的重要保证；
6、项目管理工具技能：主要包括项目管理过程中必要的IT系统支持工具方面的技能，如，project2007、P3E等，运用项目管理工具可以
   提升项目管理的效率及效果；

b) 个人项目管理培训课程体系

   上海海外人才服务中心基于对项目管理能力的深入研究和对个人项目管理能力现状的深刻理解，针对不同类型的个人对项目管理知识及
   技能的要求，以及个人项目管理能力提升的方向及路径，开发了个人项目管理能力提升培训体系，并以此为基础，提供企业内训课程的
   定制开发及培训服务。

　第四步：执行进度调整后的进度计划和确定的解决方案

　　根据偏差的处理决定，执行解决方案，调整项目进度计划。如果需要的话，通知项目干系人。项目管理论坛

　　当进度偏差比较大时，需要考虑缩小检查周期，以便更好监视纠正措施的效果，以保障项目的按期完成。

　　5. 预见性的发现和解决项目实施中的问题

　　在项目的实施过程中，项目的进度延期，实际上有很多的苗头可以预见性的去发现，发现后就可以及时去采取对策进行问题的解决，这种将问题消灭在萌芽状态的做法，可以有效的保障项目的顺利进行。下面列举说明可以预见性发现的问题及解决方法：

　　问题预见性发现问题的方法(解决的方法)：

　五 项目进度控制是不是孤立了

　　项目进度控制按照PMI的项目管理知识体系应该属于时间管理的范畴，但实际上它所包含的内容不仅仅局限于时间管理，除了上面介绍的内容外，还涉及其他的知识领域：范围管理、人力资源管理、风险管理、变更管理等一系列的内容。在这里，我就不想做太多的解释，大家可以参阅相关的资料。

本文主要从CMM和CMMI的要求出发，介绍了标准主要涉及的配置管理内容，并对相应内容进行初步地说明，最后提供了一个配置管理在项目实施的指南和一个在组织中部署配置管理的模型。 Svn8.Com

1 配置管理内容的逻辑关系

Svn8.Com

在CMM和CMMI中，将配置管理的目的定义为“建立和维护产品的完整性”，这个目标没有提到对项目管理的支持，也就是说，它定义的配置管理的目标比当前业界对配置管理的认识有些缩小。但是，仔细分析可以发现“建立和维护产品的完整性”是其他配置管理目标的基础。下面就从这个目标出发进行分析。逻辑关系见下图：

配置完整性（对标准的理解）

1. 产品完整性：就是项目提交的工作成果是“产品集合完整、子产品的正确”的 Bbs.Svn8.Com

2. 产品集合完整：产品包含的子产品（配置项）是完整的 Bbs.Svn8.Com

3. 子产品的正确：子产品（配置项）达到了需求要求，满足标准、规程的要求

Www.Svn8.Com

逻辑关系分析 参考资料:www.svn8.com

1. “基线管理”支持“产品集合完整”，明确产品的“子产品”（配置项）集合，并进行管理和控制
  2. “配置项管理”，提供了了对子产品（配置项）的控制管理，支持“子产品的正确”
  3. “变更管理”，同时支持“产品集合完整、子产品的正确”，用于控制子产品（配置项）和产品（基线）的变更
  4. “配置标示”，建立对配置项（子产品）的识别、命名，支持“配置项管理”
  5. “版本控制”，控制配置项（子产品）生命历程，保留配置项（子产品）演进历史
  6. “过程管理”，就是对配置项、基线的建立、变更的状态标示、过程控制，保证产品（或子产品）按照规定的流程进行了操作；例如“配置项”进入“基线”的过程包括：配置项标示、产品验证、进入配置、配置审计等
  7. “配置计划”、“配置库管理”、“配置审计”、“配置报告”等是整个配置管理得支持系统。提供了配置管理“可视性”和监督管理 Svn中文网

2 配置和配置项

Svn中文网

在配置管理中，“配置”和“配置项”是重要的概念，“配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置”包括了即将受控的所有产品特性，其内容及相关文档，软件版本，变更文档，软件运行的支持数据，以及其他一切保证软件一致性的组成要素，相对与硬件类配置，软件产品的 “配置”包括更多的内容并具有易变性。
  受控软件经常被划分为各类配置项（Configuraion items, CIs），这类划分是进行软件配置管理的基础和前提，CIs是逻辑上组成软件系统的各组成部分。比如一个软件产品包括几个程序模块，每个程序模块及其相关文档和支撑数据可能被命名为一个CI。一个系统包括的CIs的数目是一个与设计密切相关的问题。一个纯软件的CI通常也称之为软件配置项（CSCI）。
  现在所有的配置管理工具均提供对配置项的管理工具，包括(Check in和Check out机制的 )版本管理和版本标号功能。由于版本和标号管理比较繁琐，一般推荐使用配置管理工具，减少事务性工作。

Bbs.Svn8.Com

3 基线 Svn中文网

在配置管理系统中，基线就是一个CI或一组CIs在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，而这个过程被称为“基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素（配置项）的一个版本，且只确定一个版本。一般情况下，基线一般在指定的里程碑处创建，并与项目中的里程碑保持同步。

Svn8.Com

一般地，第一个基线包含了通过评审的软件需求，因此称之为“需求基线”，通过建立这样一个基线，受控的系统需求成为进一步软件开发的出发点，对需求的变更被正式初始化、评估。受控的需求还是对软件进行功能评审的基础。
  每个基线都将接受配置管理的严格控制，对其的修改将严格按照变更控制要求的过程进行，在一个软件开发阶段结束时，上一个基线加上增加和修改的基线内容形成下一个基线，这就是“基线管理”的过程。 参考资料:www.svn8.com

基线具有以下属性：
通过正式的评审过程建立
基线存在于基线库中，对基线的变更接受更高权限的控制
基线是进一步开发和修改的基准和出发点
进入基线前，不对变化进行管理或者较少管理
进入基线后，对变化进行有效管理，而且这个基线作为后继续工作的基础
不会变化的东西不要纳入基线
变化对其他没有影响的可以不纳入基线
建立基线的好处：
重现性：及时返回并重新生成软件系统给定发布版的能力，或者是在项目中的早些时候重新生成开发环境的能力。当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。
可追踪性：建立项目工件之间的前后继承关系。目的是确保设计满足要求、代码实施设计以及用正确代码编译可执行文件。
版本隔离：基线为开发工件提供了一个定点和快照，新项目可以从基线提供的定点之中建立。作为一个单独分支，新项目将与随后对原始项目（在主要分支上）所进行的变更进行隔离。 Svn中文网

4 基线、配置、配置项的关系 Www.Svn8.Com

基线的组成，以及配置项和配置的关系如下图：

Bbs.Svn8.Com

基线管理的步骤：
1、在开发前确定基线的“配置”
2、基线批准前，根据“配置”检查配置项是否齐备
3、对各个配置项，确认其版本的正确性
4、对每个配置项建立基线标志，
例如上图为：测试基线=（配置项A=1，配置项B=1，配置项C=1）
alpha版=（配置项A=2，配置项B=1，配置项C=1）
beta版=（配置项A=3，配置项B=3，配置项C=2）
产品基线=（配置项A=4，配置项B=4，配置项C=4）
5、基线变更管理
6、基线的各类报告和审计信息针对某个具体得项目，可以根据基线的内容，建立一个基线信息的跟踪表，例如如下： 参考资料:www.svn8.com

Svn8.Com

[注]：被色块覆盖的表示，此配置项属于对应列的基线
[注]：在色块的栏目填写对应配置项的版本号

5 变更管理

在有效标示了配置并进行了管理之后，如何保证它们在复杂多变得开发过程中真正的处于受控的状态，并在任何情况下都能迅速的恢复到任一历史状态就要依赖有下的变更管理。 Bbs.Svn8.Com

缺乏有效的变更请求管理会导致的问题：
软件产品质量低下，对一些缺陷的修正被遗漏
项目经理不了解开发人员的工作进展，缺乏对项目现状进行客观评估的能力
开发人员不了解手头工作的优先级别，可能出现将紧急的事情放在一边、而工作在一般优先级任务上的情况
可能错误使用和引用已经变更的产品，引起开发工作混乱
变更管理的流程：
（获得）提出变更请求；
由CCB审核并决定是否批准；
为（被接受）修改请求分配人员，提取SCI，进行修改；
提交修改后的SCI，并测试（或者评审）；
重建软件的适当版本；
复审（审计）所有SCI的变化；
发布新版本。 

Www.Svn8.Com

为了更好的指导变更范围的影响分析，可以通过两种表格来帮助发现受到变更影响的内容，一种是《需求跟踪表》，一种是《配置项依赖关系表》，分别如下：

Bbs.Svn8.Com

Bbs.Svn8.Com

6 配置库管理 参考资料:www.svn8.com

在实际的开发活动中系统中，为了让每个开发人员和各个开发团队能更好的分工合作，同时又互不干扰，必须规划好工作空间的管理。主要的手段是设置配置库（即文件夹设置），和设置版本的分支，来实现对配置项权限管理。

设置版本分支

Bbs.Svn8.Com

基本上要为每个配置项从建立开始就划分成3个不同的分支：私有分支、集成分支、公共（主干）分支。让它们分别对应3类工作空间。 Svn中文网

私有分支：
私有分支对应的是开发人员的私有开发空间。开发人员根据任务分工获得对相应配置项的操作许可之后，他即在自己的私有开发分支上工作，他的所有工作成果体现为在该配置项的私有分支上的版本的推进，除该开发人员外，其他人员均无权操作该私有空间中的元素。
集成分支：
集成分支对应的是开发团队的公共空间。凡是要为同组人员共享的配置项都从该分支获得。即各开发人员必须将私有工作空间中的开发成果归并（Merge）到该分支后才能进入下一个开发活动。所有涉及多人协调的开发工作（如集成测试等）都必须工作在这一空间中。该开发团队拥有对该集成分支的读写权限，而其他成员只有只读权限。该分支的管理工作由系统集成员及相关指定人员负责。 
公共（主干）分支：
公共分支对应的是整个软件开发组织的公共空间。各个开发小组在现阶段的任务完成后，将可以发布的版本归并到该分支上，将来需要查阅相关资料时，以该分支上的版本为准。该分支对组织内的全体软件人员开放只读权限。该分支的管理工作由系统集成员负责。  Svn中文网

上面定义的3类工作空间（分支）由配置管理员统一管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基线的推进。

配置库的设置 参考资料:www.svn8.com

决定配置库的结构是配置管理活动的重要基础。一般常用的是两种组织形式：按配置项类型分类建库和按任务建库。

按配置项的类型分类建库的方式经常为一些咨询服务公司所推荐，它适用于通用的应用软件开发组织。这样的组织一般产品的继承性较强，工具比较统一，对并行开发有一定的需求。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。但由于这样的库结构并不是面向和各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。

而按任务建立相应的配置库则适用于专业软件的研发组织。在这样的组织内，使用的开发工具种类繁多，开发模式以线性发展为主，所以就没有必要把配置项严格的分类存储，人为增加目录的复杂性。因此，笔者认为特别是对于研发性的软件组织来说，还是采用这种设置策略比较灵活。 参考资料:www.svn8.com

配置库的日常工作

配置库的日常工作是一些事务性的工作，主要保证配置库的安全性，包括： Svn中文网

对配置库的定期备份 参考资料:www.svn8.com

清除无用的文件和版本

Svn中文网

检测并改进配置库的性能等 Www.Svn8.Com

7 配置报告

配置状态报告就是根据配置项操作的记录来向管理者报告软件开发活动的进展情况。这样的报告应该是定期进行，并尽量通过CASE工具自动生成，用数据库中的客观数据来真实的反映各配置项的情况。 参考资料:www.svn8.com

配置状态报告应着重反映当前基线配置项的状态，以作为对开发进度报告的参照。为了说明项目状态对变更的情况也应当进行报告。有时，对配置库的情况也进行说明，例如备份次数，磁盘占用空间等等。只要是关心的信息，均可作为状态报告的内容。这些信息进行有效记录，往往可以作为项目度量的重要数据来源。 参考资料:www.svn8.com

8 配置审计

Www.Svn8.Com

配置审计的主要作用是作为变更控制的补充手段，来确保某一变更需求已被切实实现。在某些情况下，它被作为正式的技术复审的一部分，但当软件配置管理是一个正式的活动时，该活动由SQA人员单独执行。 审计机制保证修改的动作被完整地记录，也就是说，记录了谁修改了这个工件，什么时候做的修改，为什么原因做出这个改动，以及修改了哪些地方。 在版本控制过程中，如果利用一些配置管理工具（或者版本控制工具）的支持，则可以自动地记录审计工作所需的四个“W”（Who、When、Why、 What）。 同时配置审计工作应当可以说明如下信息。

Svn8.Com

配置审计应当说明的信息：
1. 变更要求被完成，并且对附加的修改已经执行了
2. 采用了正确的正式验证手段
3. 遵循了标准的要求
4. 变更的4W信息被完整记录，并和相关配置项关联 

9 项目实施指南

一个软件研发项目一般可以划分为三个阶段：计划阶段、开发阶段和维护阶段。然而从软件配置管理的角度来看，后两个阶段所涉及的活动是一致，所以就把它们合二为一，成为“项目开发和维护”阶段。 Svn中文网

一个项目设立之初项目经理首先需要制定整个项目的计划，它是项目研发工作的基础。在有了总体研发计划之后，软件配置管理的活动就可以展开了，因为如果不在项目开始之初制定软件配置管理计划，那么软件配置管理的许多关键活动就无法及时有效的进行，而它的直接后果就是造成了项目开发状况的混乱并注定软件配置管理活动成为一种“救火”的行为。所以及时制定一份软件配置管理计划在一定程度上是项目成功的重要保证。

Www.Svn8.Com

在“开发阶段和维护阶段”，软件配置管理活动主要分为三个层面，这三个层面是彼此之间既独立又互相联系的有机的整体。 Svn中文网

（1） 主要由配置人员完成的管理和维护工作；

（2） 由系统集成员和开发人员具体执行软件配置管理策略； Svn中文网

（3） 变更流程。 Bbs.Svn8.Com

10 配置管理部署模型

基本过程 Svn8.Com

Bbs.Svn8.Com

相应操作文件 Bbs.Svn8.Com

对应过程：2.2了解员工对配置管理的态度建立一个CHECKLIST，来进行调研，如下

对应过程：2.3了解组织的配置管理技术水平建立一个CHECKLIST，来进行调研，如下

Www.Svn8.Com

对应过程：3.2评估配置工具供应商建立一个CHECKLIST，来进行调研，如下

Bbs.Svn8.Com

对应过程：3.2评估配置工具供应商建立一个CHECKLIST，来进行调研，如下 Bbs.Svn8.Com

对应过程：4.2制定新的过程1. 配置管理过程至少应当包括的内容：配置标示、配置控制、报告、审计2. 在考虑工具纳入配置过程中应当考虑下表内容 Www.Svn8.Com

对应过程：6.1组建相应部门和团队负责配置管理部署和实施的团队必须包括

参考资料:www.svn8.com

对应过程：6.2制定各个项目的实施计划计划应当包括的内容： Svn中文网

4.3 企业内部的项目立项

企业中的项目要动用企业的资源，所以就企业内部项目立项的本质来说，企业中批准了一个项目就如同批准了一项投资。从公司治理机制和企业财务管理的角度来说，投资都是需要经过论证、审批的，不同的投资规模需要不同权限的管理者的批准。
在企业内部实行项目管理，一般都会有立项的过程，但是，是所有任务都要正式立项，还是只有部分任务需要正式立项，划分的标准是什么？项目能否通过立项的审批标准是什么？正式立项对后续的项目管理应产生什么影响？在建立企业级项目管理体系中，有许许多多的管理思想和要求，都会在立项过程中集中体现出来。
项目的立项，属于项目管理五大过程中的启动过程。无论作为甲方还是乙方，当企业运用项目管理方法时，项目的立项环节，是企业对整个项目进行管理的重点环节。企业在立项过程中所确定的项目目标、范围、投资规模、时间要求、各种假设和限制条件，都直接决定着项目后续的各个过程中的工作。管理好立项环节，是企业加强项目管理的一个重要环节。

4.3.1 什么样的项目应该正式立项
首先，我们看看企业通常会在什么情况下进行正式立项：
 为按期完成一个合同定单而需要组织专项的资源投入，并核算项目绩效；
 为规避长期投资的风险而通过项目立项来明确阶段性目标；
 通过项目成本管理来核算一个产品的研发成本以便对所形成无形资产估值；
 为了使客户满意，保证对重要客户的专项服务而需要形成专门的项目组；
 为了提高企业内部跨部门的沟通协调的效率而组成跨部门的项目组；
 为了协调企业内部权力平衡（或绕开原有不适合的人事布局）而形成非常规的项目管理方式和报告路线；
 对老板关注的任务正式立项，以便能够重点监控，及时进行专题报告；
 为了借用项目管理的方法对任务执行过程进行跟踪管理；
 为了在立项后能够为项目经理或项目组成员提供一些额外的补贴；
。。。。。。
上述这些情况，在现实当中都是实际存在的。通常情况下，正式立项本身就需要一个比较规范的程序，而后也需要一系列较为规范的跟踪报告程序，然后还要有正式结项的手续。这些都是管理成本，如果不是十分必要，就一定不要为了项目管理而立项。那么作为一个企业在建立企业级项目管理体系时，应该从哪些方面来考虑是否需要在企业级立项呢？
 

在企业级正式立项的项目，应该具有以下的某些特征：
1， 任务本身具有明确目标、适合采用项目方式进行管理；
2， 项目规模较大，项目执行过程中的问题或项目的结果，都可能会对企业的经营管理产生直接影响的任务；
3， 项目资源超出现有的某个部门而涉及企业中更大的范围，需要由管理层进行协调；
4， 项目目标或项目过程中将面临的问题都是企业原有的制度流程所不支持的，需要设计专门的组织管理方式；
5， 对外宣传需要的；
相比之下，不适合采用项目方式进行管理的任务，还有那些局部的、规模很小的、对企业影响甚微的任务，无论是否可以采用项目管理的方法进行管理，都不一定要在企业级进行正式的立项。

例如，在某企业当中，销售人员接触新的客户寻找商机的过程，由于不确定性非常大，所以通常都不按项目进行管理；产品部门根据客户的反馈对产品做出一个极其微小的修改而发布一个软件补丁，通常也不需要立项；
 

4.3.2 根据自身特点定义企业中的“项目”
在企业中，项目管理是一种方法，不一定是某种特定的组织形式。企业可以根据生产、管理的实际需要来运用项目管理方法，定义企业自己的“项目”。
在通常情况下，客户方以项目的形式组织工作，那么任务承担方则会组成一个项目组，来配合完成这一任务，也就是说，一个订单就会对应一个项目，这个项目完全是为实现这个订单服务的。这样对于项目目标、项目周期、项目成本核算等，都会比较容易明确。这是最常见的一种情况，但是在许多情况下，企业中不把项目与订单一一对应起来：
1， 把来自客户的一个大项目，在内部划分成若干小项目。例如客户的项目范围很大，涉及问题很复杂，为了便于管理，企业内将项目范围划分成几个部分，每个部分之间的产品、技术服务、进度要求等都不尽相同，将这些部分分别成立不同的项目组来完成，从而简化了项目管理的复杂度。这时，企业对应一个来自客户的项目，在内部实际形成了若干个项目，这些项目都是客户项目的子项目。在这种情形下，就需要一个针对客户项目的管理组织，通常会成立一个项目级的PMO，来协调这些子项目，保证客户项目的整体完成。
2， 把来自客户的一个周期较长的项目，按照项目的阶段划分，在企业内部分阶段立项。例如客户的一个大型信息系统的外包项目，需要做前期的可行性分析、总体的设计和开发、系统的部署，以及后期的维护等，这样一个项目建设周期在两年以上。为了便于管理，企业在征得客户的同意后，在每个阶段分别立项，即每个阶段成为一个子项目，简化了管理的复杂度，并且大大节约了在项目阶段之间由于各种原因出现的空闲时间间隔所造成的资源闲置，同时也便于各个阶段的子项目，能够针对前一阶段的结果，更有针对性的制定本阶段的项目计划。
3， 把非常类似的多个外部项目，在企业内合并成为一个项目。例如同时接到对于同一产品的多个订单，在产品技术要求、周期要求等方面都几乎一致，这时企业就可以将这些订单合并在一起，在内部形成一个项目， 来完成所有这些订单的要求。这样对于企业来说，生产效率就会比较高。
4， 有些产品供应商，是在完成客户项目的过程中，来改进企业自有产品的。这种情况下，企业会成立内部项目。内部项目的范围，不仅包括完成外部客户的项目需求，还包括了自有产品改进的要求。在这类项目中，在项目范围的确定、项目活动的安排、项目交付物的要求等方面，就需要同时兼顾外部客户和内部产品两方面的要求，往往在客户项目验收完成后，内部项目还不能结束，还要继续完成产品改进的后续工作。
5， 在一个大型的组织内，不同的管理层对项目的定义是不同的，例如在一个大型集团企业中，有集团级项目，有公司级项目，还可以有部门级项目，在不同管理层定义不同的项目，这些项目之间还可能存在着一定关联、归属关系。他们之间有些像多项目、单项目、子项目之间的关系。出于不同的管理层，对“项目”的含义会有不同。

很多企业的项目都是由内部的部门来承担的，例如大企业的信息系统建设项目，通常都是由内部IT部门来承担的。在这种情况下，更需要注意项目管理的内外有别。在承担项目任务的部门中，也同样要有所区分，上述几种情况也都有可能会出现。
正是由于这种可能存在的内部与外部的项目范围的不同，当企业的项目管理需要内外有别时，就必须强调工作范围的管理，管理粒度不能停留在项目这一级上，而是要管到更具体的项目中的工作任务，管到项目WBS中的具体模块，这样做就可以为企业提供更大的灵活性，面对众多的外部项目任务，在企业内部可以重新组合这些工作任务，形成不同的内部项目，只要企业内部能够管理好项目的范围，充分做好合同管理，最终能够做到满足外部项目工作范围等要求即可。

4.3.3 项目立项的不同时机
对于项目立项的时机，在不同企业中有不同的要求，例如：
 企业中在完成可行性分析之后就开始立项，只需说明项目的目标，大致的方案，粗略的周期和费用的估算。然后具体的方案决策、计划的制定，都是在项目中完成，这些也属于项目的工作范围。在项目过程中，随着项目的进展，不断对后续工作的范围、周期、预算进行细化明确。通常企业会将可行性分析单独作为一个调研项目，然后再根据分析的结论作出决策，决定下一步是否继续进行。如果要继续进行的话，通常会另外重新立项。但是也有的企业在最初的时候立项，以后只对各个阶段进行计划和审批。
 企业中前期的项目方案决策结束后，开始办理立项手续，立项手续就是一张表格，只需要说明项目名称、项目周期、项目组主要角色、项目预估的工作量，然后由有关的领导签字批准，即可立项。立项后再由项目组开始编制项目计划，项目计划由另外的机构来具体审批。。
 企业中将项目视为一项投资，不仅要完成前期的可行性分析、确定方案，并且要给出较为详细的项目计划和预算，才能够批准立项。这时立项手续中所要求的内容较为全面、具体。
这些不同的立项管理的方式，它们在项目整个过程中的时机不同，所要求提交的说明材料的内容要求不同，企业对项目的控制力度也不同。

立项的手续通常都是企业中批准项目资源、预算的手续。在上图中，企业中的项目办理立项的时机不尽相同，可以在项目启动过程前，也可以在启动过程结束且制定项目计划之前，还可以在制定项目计划之后。但是这并不改变从项目意图、可行性分析、确定初步的项目范围和成本进度及成本估算、编写项目计划，直到项目执行的这样一种过程。因此，企业在不同环节办理立项手续，所要求的立项条件是不同的，立项文件中需要说明的内容自然也是不同的，需要根据企业自身及项目的具体管理情况做出规定。
 

4.3.4 立项审批的条件
无论企业中的立项手续是在实际项目的哪个阶段进行，都会经历项目的五个过程，阶段与过程的关系已经在第一章做了说明，因此，无论企业中如何确定立项的时机，立项时都需要明确项目启动过程的两个主要子过程，就是编写项目章程（Project__ charter）和定义初步的项目范围。见下图：

PMBOK中对项目章程和初步的项目范围说明书，都给出了较为具体的说明。具体要求如下：

 项目章程
项目章程是正式批准项目的文件，授权项目经理在项目活动中动用组织的资源。项目章程的内容包括：
1， 为满足客户、出资人及其他干系人的需要、期望而提出的要求；
2， 商业要求、高层项目说明或本项目中的产品需求；
3， 项目目标及其合理性；
4， 指定的项目经理极其权限；
5， 总体里程碑进度表；
6， 利益干系人的影响；
7， 职能组织及其参与的影响；
8， 组织的、环境的、外部的假设；
9， 组织的、环境的、外部的限制条件；
10， 支持项目的商业案例，包括投资回报；
11， 项目总体预算；

 初步的项目范围说明书
初步的项目范围说明书是利用项目发起人或出资人提供的信息编制的，是以后项目范围定义的基础，其内容包括：
1， 项目与产品的目标；
2， 产品或服务的要求与特性；
3， 产品验收标准；
4， 项目边界；
5， 项目要求与可交付物；
6， 项目限制条件；
7， 项目假设；
8， 最初的项目组织；
9， 初步识别的风险；
10， 进度里程碑；
11， 初步的工作分解结构；
12， 大致的费用估算；
13， 项目配置管理要求；
14， 审批要求；

项目启动过程的输出，指出了应该提供的项目信息内容。从上面的内容可以看出，这些内容主要反映的是项目的外部特征，是后续制定项目计划的重要依据。就像我们在软件开发中，先要定义模块的功能和输入、输出接口，作为以后进一步考虑模块内的具体编程方法的依据。这一指导规则说明，在项目被批准前，应该能够就项目的大致情况提供出必要的信息。
上述内容只是PMBOK的一种建议，具体企业由于立项的时机和要求的不同，对于立项时需要说明的内容，很有很大差别。各企业需要根据自身的管理流程和管理要求，制定出符合企业自身的具体规定。
当申请正式立项的项目，首先应能够按照企业所规定的要求提供比较明确的立项输入输出内容，充分说明项目的必要性和可行性，然后才能由企业管理层进行审批。立项审批通过通常需要同时满足以下几个条件：
1， 项目目标符合企业的发展需要；
2， 项目本身在市场、技术和财务方面具有可行性；
3， 企业能够获得项目所需的资源，使项目能够在规定的时间内完成；
4， 项目中的风险可以得到有效管理；
 

4.3.5 项目优先级
当企业中同时存在着多个项目时，就不可避免的存在着项目优先级。同时进行中的项目有时会发生冲突，特别是在资源竞争方面的冲突，例如项目资金、人力资源、工作场地环境、机械设备等，在发生冲突时，企业不可能为了解决临时的冲突而准备最大的资源支持，而是按照一定的优先级来进行协调，这样可以大大降低企业的成本，保持资源的最大利用率。
通常情况下，在企业中根据企业的市场特点、根据企业中项目的普遍情况，企业会制定一个基本的项目优先级的标准，然后再结合具体项目的特点，在立项时就给项目安排一个优先级。这样，就可以给企业各方面的管理者提供一个清晰的指引，当项目资源发生冲突时，就可以按照项目优先级来提供支持，使企业的当前发展重点能够得到保证，是企业级项目管理体系中的基本内容。
举例：
这是一个简化的某商业银行项目优先级排定的示例，主要从项目的重要性、紧迫性、确定性和资源占用这四个方面考虑项目优先级：
 重要性
- 外部监管部门要求的，如人民银行、银监会、审计署等
- 国际组织统一要求的，如SWIFT、国际信用卡组织等
- 为企业战略行动提供支持的，如上市、机构重组、战略转型等
- 对系统稳定、高效运行影响较大的，如影响年终决算、影响正常营业的
- 对业务发展、市场竞争影响较大，受行领导高度关注的
- 对市场、外部客户承诺的
- 对整体IT架构产生影响的
- 有对外合同约束的
- 业务部门（内部客户）高度重视的
- 其他
 紧迫性
- 系统投产要求的时间顺序
- 使用了外部资源有时间合同限制的
 确定性
- 业务需求明确
- 技术方案确定
- 各部门、中心的项目组织、配合关系明确
- 总体时间表明确
 资源占用
- 占用资源较少的
- 使用企业外部资源的

利用上述列出的考虑因素，按照下列步骤依次划分优先级：
1，按照重要性区分项目的高、中、低等级，并排序
2，在重要性等级相同的项目中，按实际要求的完成时间排序，有时间要求的为高，没有完成时间要求的为低
3，在前两项等级相同的项目中，按照各因素确定性排序，明确的等级为高，不明确的等级为低，部分明确的等级为中
4，在前三项等级相同的项目中，按照资源需求情况划分，需要资源少的优先，使用内部资源的优先
5，如果某项目是其他项目的依赖前提，其优先级与后续项目优先级最高的相同

通过上述步骤，在这张表中将会形成一个项目优先级清单。这里并没有采用定量的计算方法，而是根据不同客户的具体特点，采用了定性分析方法。

4.3.6 企业内部立项中的常见问题
1， 立项时“拍脑袋”决策。
在许多企业中，立项的过程其实就是项目决策的过程，在立项过程中要对项目的可行性进行论证。但是经常由于“领导意志”或“老板意志”而使决策过程过于草率，仅凭某些高层管理者的主观判断做出决策，随意性大。
也许大家听说过“六拍”：立项时领导“拍脑袋”，承接任务时下属盲目“拍胸脯”，领导看到勇挑重担的部属“拍肩膀”，等项目的问题难以收拾时“拍桌子”，项目经理万般无奈之下只好“拍屁股”走人，此时领导只能懊悔的“拍大腿”——悔不当初啊。

2， 立项手续只是为了走形式。
在某些企业中，项目立项的手续只是走走形式，有的立项材料过于简单甚至没有，主要就是一张需要各方面签字的立项审批单；有的是项目立项时所规定的时间、预算并没有成为项目计划的基线，可以随意突破而无人监控；有的直到项目快结束时才办理立项手续；等等。这种现象也是许多企业中的常见问题。存在这种情况的企业，需要仔细思考一下自己企业中设置立项手续的目的是什么，如果确实不需要的话，不如干脆省掉，还能为企业节约一些管理成本。如果确实需要立项管理，那么就要认真执行自己所制定的管理制度，对项目进行指导和约束。
从立项审批就是企业投资审批的角度来说，如果立项手续只是为了走形式，那么企业的财务管理一定存在问题，比如有的项目快结束时才补办立项手续，就相当于项目组先动用了企业的资源、花费了企业的资金，然后由老板买单，造成实际控制权的转移。即使项目是必定要做的，这种造成既成事实后的被迫买单，也是企业管理中的一大漏洞，成为一些人钻空子的机会。

3， 不立项就不进行项目管理。
也经常遇到这样一种情况，由于某些任务没有在企业正式立项，或者立项手续尚未完成而某些项目工作已经启动，此时任务的负责人（现在还不能叫做项目经理）在管理中完全抛开项目管理的方法，管理极其随意，理由就是因为还没有立项，所以企业的项目管理规范可以暂不遵守。这是对项目管理方法与企业项目管理制度的错误认识造成的。项目管理是一种方法，是项目经理的工具，企业的项目管理制度只是在此基础上结合企业的具体情况进行了细化，是企业对项目的要求，立项是企业管理项目的方法之一，企业立项与否并不影响具体项目负责人使用项目管理的方法，两者并不矛盾。从企业角度来说，即使没有正式立项，企业也需要对各项任务进行管理，只是管理的方式会有所不同。

　　图1 制造业产品生命周期管理系统

　　产品生命周期管理(Product lifecycle management，PLM)是一种战略业务方法，能够更好地将产品推向市场，可以从生命周期的角度最大化产品的价值，并使产品生命周期信息透明化，企业结合信息系统和商业系统，建立起把产品带入市场并且到它的生命尽头所有过程中的所有信息。为制造商和供应链合作伙伴进行有效的合作提供产品信息支持。借助于产品数据管理软件系统，企业可以实现研发部门、其他相关部门甚至企业间对产品数据的协同应用，从而达到合理设计利用企业内部各档次产品的产品生命周期，降低产品的综合成本，提高产品质量，缩短新产品投入和产出时间，实现企业利润的最大化从而提高企业的核心竞争力。PLM涉及的技术非常广泛，包括并行工程技术、虚拟制造技术、统一数据模型技术等等，将这些技术应用到系统集成中，就成了用户终端使用的PLM系统，如图1所示，根据功能不同。PLM系统主要有电子仓库、文档管理、产品结构与配置、零部件管理、工程变更管理、项目管理等几个功能模块。企业从战略角度出发，以产品为核心，建立从产品研发、制造、销售到售后服务等环节的管理体系，实现了对企业工程文档、BOM结构、工作流程生产计划、产品质量、ERP系统的有效管理。基于Internet技术，不同部门可以使用企业单一的产品数据源和与产品一致的产品信息管理，确保正确的人员在正确的时间，以正确的方式访问正确的信息。作为PLM系统的一部分，CRM、SCM等系统的发展，可以将制造企业、合作伙伴、供应商及客户联系在一起，由此可见，PLM作为一个信息桥梁．允许制造企业及其合作伙伴，在整个生命周期内对产品进行设计分析制造和管理。

　　2 基于PLM的项目管理内容

　　项目是为提供某项独特产品、服务或成果所做的临时性努力。而项目管理是指通过项目负责人和项目组织的努力，运用系统理论和方法对项目及其资源进行计划、组织、协调和控制，旨在实现项目的特定目标的管理方法体系。项目的整个过程可以概括为前期立项、计划实施期以及评估结束期三个阶段。在整个项目管理的生命周期内，范围管理，时间管理，成本管理，人力管理，质量管理，沟通管理，风险管理，采购管理及集成管理构成一个完整的整体，尤其在时间管理，成本管理和质量管理方面，使项目管理的有效性得到了极大提高，如图2所示。

　　图2 项目管理体系

　　2.1　时间管理

　　在项目任务分解和资源配置后，需要对项目的任务工期进行估算，进而对项目的整个工期进行计划和管理，PLM在建立任务时给出时间估算，它可以是某一个区间数甚至是一个时间分布概率函数，根据各任务之间的关系计算出每个任务开始时间和结束时间的统计特性，进而计算出整个项目完成时间的统计特性，从而可以判断项目能够以多大的概率按时完成，在时间管理方面，除了时间管理和状态管理外。对任务定义多个后续任务时，PLM系统可以定义在执行任务时选择哪个后续任务的判断条件。从而支持在执行时自动判断系统中的可行任务集合，根据任务占用的资源数量和任务的优先级从可行任务集合中选择执行的任务，PLM系统项目管理中各项任务的输入输出数据及对数据对象的审批、发放能够使任务的输入条件或输出条件得到满足，使任务的状态发生变化，并通知相关人员进行调度资源和任务，是并行工程技术甚至多项目管理的有力的技术支撑，从而使项目进度、成本和利润达到最佳的平衡。

　　2.2 成本管理

　　在开发的早期阶段选择基本的设计方案时，产品的生命周期成本就已经确定，包括流程的选择也会影响项目的实施周期和成本，工作分解结构初步确定项目所需资源需求，资源需求包括项目所需的资源种类和数量，根据资源单价就可以确定跟时间无关的资源成本，根据时间估算的结果，可以计算与时间有关的人工、设备和资金的使用成本，由于PLM与ERP系统的有机连接，项目的成本估算变成了工作分解后的简单计算，而且在项目更改及时间延后时，项目管理人员能清楚知道项目成本变化及对整个项目盈利的影响。除了执行项目本身的成本外，产品开发成本(项目执行成本)虽然只占不到产品生命周期成本的20％，但是制造业产品生命周期成本的80％是在产品设计阶段决定的，通过PLM系统与企业制造系统的无缝集成，企业能够在所有的产品配置中进行数字化的优化与验证任何制造工艺和流程，能够有效降低产品生命周期的成本。

　　2.3 质量管理

　　传统的质量控制仅仅对制造过程进行控制，实际上，产品的研发形成过程也伴随着产品质量的形成过程。影响质量的因素贯穿于产品的整个生命周期，仅仅对制造阶段进行质量控制并不能最终保证产品的质量要求，结合传统的质量工具，如质量功能展开(Quality Function Deployment)、试验设计技术(Design of Experiment)和68设计(Design for Six Sigma)，PLM的一些关键技术如虚拟制造技术、统一数据模型技术等能够尽早发现产品设计中存在的质量缺陷，避免在制造阶段昂贵的修改费用，从而大大缩短产品研发试验时间和成本，研究表明75％的错误是由产品研发形成阶段引起的，80％的修改工作是在产品制造阶段或是后续制造阶段完成的。综上所述，借助于PLM系统，企业可以在产品研制和生产活动中实施集成化质量管理系统，不断改进企业的产品质量管理能力。

　　3　基于全生命周期的项目管理在汽车零部件项目管理中的应用

　　汽车研发过程具有目标明确，参数要求多，市场时效性强，人力物力资源消耗量大等特点。这需要汽车零部件企业在时间、成本和质量性能条件下，尽可能高效地完成研发任务。

　　3.l 实施案例

　　N公司设计工作往往都是在总的产品设计定型后，才开始分部件的开发设计，零部件的产品模型有一定的单一性和片面性，由于各零部件的设计相对孤立，造成设计信息不能在设计团队中互相共享，且原始的图纸版本控制也非常混乱，不利于数据安全及管理，使产品开发效率受到极大影响。由于各种设计信息相对孤立，造成并行工程中倡导的模块化设计得不到很好的执行，零件的通用性大打折扣。为了解决上述问题，公司决定引进PLM软件，对所有产品信息和相关过程进行规范管理，建立统一的设计平台，提高数据共享性，实现协同开发及并行工程，缩短产品设计周期，更好控制项目进度。针对N公司的实际情况，PLM项目组成员决定选用Matrixoile公司提供的MatrixlO，Matrix PLM平台，Matrix One对所有的文件实行文件级管理。同时对必要的元数据信息进行管理，通过工作流程管理自动实现数据传递控制。实现了分析结果和设计文档在设计人员之间的无缝传递。通过Intralink，基本实现了Pro/E与Matrix One的紧密集成，Pro／E可以与Intralink直接集成，Intralink直观的用户界面提高了效率，简化了数据管理活动，提高电子仓库和Pro／ENGINEER模型、关系和功能的修订管理，控制个人和小组层面的信息访问权，更好地管理何时允许变更、谁能作出变更，并广泛地沟通变更。同时，Intralink还是一个功能强大的搜索工具，有助于设计的重复使用；MatrixOne与Intralink之间通过映射进行数据交换，通过以上方案，实现了Pro／E和MatrixOne的双向数据交换。新产品开发项目管理流程与MatrixOne的集成相对简单。通过协同应用组中的program central模块，将已经定义好的工作流程在MatrixOne中进行定义，实行新的系统后，项目经理只需要根据系统预先的定义，针对不同的业务对象选用不同的产品生命周期。即可在创建这一项目时，自动启动相关的项目管理流程，并给相关的项目团队成员下达不同的任务，通过公司邮件系统，自动发送任务通知和任务提醒。

　　3.2 实施效果

　　通过Matrix 10的实施，N公司建立了一个以Matrix 10为中心的统一的、安全的协同PLM平台，使得公司可以与其产品生命周期的所有合作伙伴都在同一平台上，Matrix PLM组件、协同应用组件和生命周期应用组件形成了一个比较完整的协同PLM组件，极大缩短了公司项目开发周期，降低项目开发成本，提高了项目开发的整体效益。

　　3.2.1 项目计划和进度管理

　　公司实施Matrix 10后，项目经理可以组建一个虚拟的全球性的项目团队，计划和协调在项目每个阶段的关键活动，分配和组织与项目相关的各项任务。具有实时日程安排功能的任务列表会随着每个任务的完成自动更使新，从而使项目的进度和状况对整个团队是透明的。这样就极大避免了经常性的电话会议和进度确认，突破了项目组织的地域和时间限制。而且，借助program central，项目经理可以直接创建和管理项目进度计划，并可以在全球性的项目团队内进行任务分配。由于与MS Project的双向集成。项目经理也可以先用MS Project创建进度表和资源分配信息，再导入到Program central中执行和监控。

　　3.2.2　项目权限管理

　　项目经理可以建立项目层面的安全权限，通过设定访问项目的各种权限，对每个项目内的文件夹和文件权限进行控制，同时，系统管理员可以设定整个系统的权限，如项目财务状况等敏感信息。通过这个功能，项目领导能够及时获取和管理项目成本和收益的估值，借助于Program Central的工作流管理，项目小组成员可以创建一个特定的工作流。将相关的成员联系起来，共同完成某个任务或审批某个文件。

　　3.2.3 管理层仪表板(Dashboard)

　　仪表板为项目提供了更高层面的视图，从仪表板中可以直观地了解到项目生命周期的各个阶段。如风险级别，质量要求，评估效益，成本和投资回报率等。高层管理人员和项目领导可以通过仪表板迅速得到关于项目投资收益率，风险评估，进度报告及任务状态的高层图表报告。借助系统的自动超级链接，管理层可以深入地了解某一个报表更为详细的信息。除了项目层面的报表，管理层和项目组可以实时查看项目产品的关键指标和规格要求。

　　3.2.4　项目模板

　　由于汽车零部件行业的产品有比较大的相似性，许多项目的开发流程也渐渐标准化，公司将任何产品的开发流程定义为七个阶段(Phase)：概念阶段；项目定义阶段；设计开发阶段；产品验证阶段；正式生产阶段；售后维护阶段；项目审核阶段。每个阶段通过关口(gale)来控制，在七个阶段中，分别应用了公司的日常流程来实现每个阶段的任务，如收集客户要求(Voice of customer)，项目定义和可行性评估，市场启动计划。产品设计，生产工艺设计等等。通过项目模板功能，企业原先的针对风险级别设立的标准化流程可以直接在系统中设置成不同的模板，新的项目在指定计划时就可以直接按照某个模板来创建，其WBS、文件夹结构、文档模板等都可以从模板中继承，使项目计划和创建的过程大大简化。

　　通过Matrix One系统的实施，公司实现了产品生命周期内的全数据管理，优化了公司现有的产品开发流程和项目管理流程，形成了一套完善的产品知识管理体系，是实现项目管理成本控制，确保项目进度的非常有效的手段。

　　4 结束语

　　本文描述了产品生命周期管理系统的功能框架，分析了汽车零部件企业在产品研发过程中存在的问题，建立了基于PLM平台、面向产品开发全过程的项目管理模型。通过在企业的实际应用，证明了基于PLM面向汽车零部件研发的项目管理的实用性。随着现代项目管理理论的发展，出现了一些新的问题，例如如何在多项目下的资源约束条件下进行项目管理，如何对项目进行全程动态的风险管理等，为了实现产品生命周期内的项目管理，使PLM系统真正成为一个全生命周期的平台，需要对以上问题进行进一步的研究。
原文： http://cio.it168.com/a2010/0531/949/000000949334_all.shtml