点击图片或这里下载：配置管理从理论到实践 (165)

许多非技术出生的网民往往会将企业内部禁用QQ视为对QQ的不信任，其实这里面有过分解读之嫌。像盛大腾讯禁用QQ根本就不应成为新闻，一直以来，笔者接触的很多企业不仅仅是限制QQ使用，而是限制公司员工尤其是研发部门的员工的一切上网行为，企业内网与互联网是完全隔离。一边是互联网带给员工工作所需的丰富的知识信息，一边是企业信息安全需要得到保障，在两者不能兼顾时，更多的企业采取了全面禁网的措施，实属无奈之举。

企业的这种看似极端甚至有些自残的做法并不是杞人忧天，如果允许员工随便访问互联网，可能会给企业带来的信息安全漏洞到底有多大呢？下面我们来稍微分析一下。注意下文中提到的所有泄密途径只是从技术上加于分析，并不代表说这些软件就一定会导致企业信息泄密，这里只是指出了存在泄密的潜在可能性。

如果企业内网与互联网完全相通，即员工的计算机即可以访问内网又可以直接访问互联网，那么根据员工使用的软件的不同，大致可分为下列两种情况：
一：桌面软件（C/S架构)
现在几乎所有的桌面软件都会或多或少的通过互联网向外发送信息，具体又有两种情况：
1：一种是软件本身的服务就是C/S架构的，类似于QQ，一个不连接服务器的QQ客户端是完全没意义的。这种情况下，所有的用户数据都会提交到服务提供商的服务器上，因此这种客户数据的安全性完全依赖于这些软件服务商的自律，而这需要建立在用户对服务商完全信任的基础上。一般的小公司大多会信任大公司的产品，这里面小公司也存在一个侥幸心理：大公司估计不会关注到我们这种小公司吧。但是如果是两个同样量级的竞争对手，让他们还能够彼此完全信任，这就不大现实了，这也是大家认为盛大，百度这类公司内部禁用腾讯QQ是为了防止其截取机密的一个直接原因。

说来也怪，比起国内企业的软件服务，更多的企业更愿意信任Google这类国际大公司的产品，笔者接触到不少国内创业公司都在用Google Calendar，Gmail等服务，有些甚至将整个公司的业务信息都上到Google网络上了，如果你问他们是否担心Google会偷取他们的数据，他们一定会说不会怀疑Google会这样做。

2：另一种情况是软件本身的功能并不依赖于外部服务器，但是这类软件会有如下几个正当的理由来告诉使用者它需要向外部发送信息，这些信息包括：自动升级检测，软件崩溃报告，旨在改善用户体验的使用数据，卸载报告等；但是这些软件是否会进一步收集用户的数据呢？这个就很难说，因为这些软件向外部发送到数据并不能很好的被监控和分析。因为很多数据并不走明文，就更难监控这些软件的行为了，而有些共享软件本身就是靠这个活的。

现在越来越多的软件厂家意识到占领用户桌面的重要性，从输入法，杀毒软件，即时通讯工具，播放器，网盘客户端等种类繁多的桌面软件就看得出来这方面的竞争有多激烈。但是，如果这些软件都不提供联网功能，大家可能就不会觉得这类桌面软件有多重要了，这里面软件提供商除了可以得到一个广告渠道外，能够收集到大量的用户数据（当然不一定都是隐私数据）也是一个重要因素。

二：外部网站（B/S架构）
相对于C/S架构的软件，B/S架构的外部网站的服务是通过浏览器提供的，则相对来说安全性要更有保障一些，至少从根本上杜绝了软件扫描整个客户计算机以窃取隐私信息的可能性。同样这里有两种情况：
1：员工访问网站知识为了获取信息而几乎不会存储任何信息，例如员工访问google或baidu以获取某个技术问题的解答，或者员工通过一些论坛，博客获取到一些与业务相关的研发知识，这类访问相对来说要安全些，但是也同样存在一些泄密的可能。笔者就知道曾经有家公司就发生过因为员工将机密文档上传到外部网站而导致泄密的事件。

2：有些公司的员工使用互联网服务提供商提供的SAAS服务来存储公司的业务信息。现在越来越多的“云服务”提供商为企业提供各种各样的服务，这些“云服务”商如果不能解决用户信任问题，又有哪个公司愿意将自己的所有机密信息（特别是公司的产品研发数据）放到这些外部服务器上呢？这也是目前SAAS的服务对象主要还是面向中小型企业和团队的一个重要原因。

中国的有些互联网服务提供商并没有把用户信息安全当回事，这一点就不得不提一下前段时间发生的某些知名网站用户密码泄漏问题：将用户的密码以明文的方式存入到系统中本身就是不尊重用户信息安全的行为，并且这种做法的真实动机很让人怀疑，任何WEB系统都应该从设计上保证用户的密码只有用户本人知道，任何其它人（包括网站的系统管理员）即时获取到整个用户数据库都无法通过技术手段解析出用户的密码明文。那些存储用户密码明文的系统我想只有两个理由：低劣的开发人员的恶心设计；服务提供商不怀好意的有意为之。即使出了这么严重的大面积用户密码泄漏事件，你仍然可以发现国内目前还有一些网站继续这么干，笔者前几天正好使用了一个网站的密码找回功能，结果它直接往我的注册邮箱中发送了一个我的密码明文，找回这个明文密码并没有让我有一丝高兴，反而觉得恶心之极,这个网站还是一个政府主导的大型市民服务网站，怎么会有如此恶心的设计。

笔者所在的公司方向正好是为企业提供研发协作平台解决方案的，有客户以为我们的系统是基于SAAS的，这时就会问一个问题：我所有的研发数据都放到你们的系统中，如何保证这些数据的安全性。当知道Topo尽管是一个B/S架构的服务器软件，但是并不是基于SAAS的，系统是安装到他们公司自己内部的，这时才能完全打消他们的顾虑。如果是SAAS服务的话，还真不知道如何解释才能够让他们完全信任。这里还有一个能够反映企业对数据（尤其是研发类敏感数据）的安全性非常重视的例子：当用户反馈Topo系统问题时，为了定位这些问题，希望用户能够提供服务器运行的log数据，这时我们会明确告诉用户说你提供给我们的log数据是全文本可读的，用户可以逐个检查一下这些log文件的确没包含任何用户数据信息后再发给我们，从而从根本上取得用户对我们的信任。要取得用户的信任，首先你要值得用户对你信任，目前有些软件动不动就向外部服务器发送一大堆不可阅读的二进制内容，你让用户如何完全信任你？

诚信是任何社会中最普遍、最基本的伦理价值需要。诚信的基础在现今中国社会受到了动摇的同时，互联网企业的信任危机也越来越严重，更何况互联网上太多的截取用户隐私的流氓应用，前不久的3Q大战，刚刚平息的知名网站用户信息泄漏事件，这些都让广大中国网民伤不起。任何公司要想取得用户的信任，首先必须是值得大家信任，在这方面，中国的互联网公司的确还有不少的事情值得去做。

尽管本文分析了公司员工访问外网可能存在的诸多信息泄密可能漏洞，需要指出的是，与担心服务提供商非法窃取商业信息相比，大量公司给员工断网的更大原因还在于防范员工主动泄密。为了达到防范员工的目的，断网还不算狠的，更狠的是封USB口，锁主机，甚至禁用有拍照功能的手机等，说到底，企业为了保护自己的商业秘密，做任何措施都不为过。

相信看到这里时，你不会还觉得盛大百度内部禁用QQ有啥好奇怪的了，相反，如果你所在的公司内部还能任意访问互联网，你应该感到庆幸，也许明天你的老板看到这篇文章后就决定断网了？

本文由国内领先的研发协作系统提供商CLOUDTOPO供稿，欢迎转载。

杭州云图科技的观点：

如果代码管理是楼主定义的这个范围，我觉得还是分开好。但如果是我下面要讨论的代码管理的范畴，则要视研发团队应用工具的水平而定。如果应用工具的水平比较高，合起来好，如果目前团队应用工具的水平刚刚起步，还是分开比较好。

我们理解的代码管理工作包含下面几个层次和范围：
1）代码库的管理。
首先你需要寻找一款合适的版本管理工具。版本管理工具有哪些？商业方面的有IBM的ClearCase，微软的VSS，开源方面的有CSV,SVN,GIT等。 版本管理工具并不局限于管理代码，国内很多研发团队还用它来管理资料和文档等。
版本管理工具都需要客户端软件，例如SVN的TortoiseSVN，使用它来check in/out，merge以及管理branch等基本操作。这些操作也是楼主上面提到的哪些操作。

2）代码源代码深度查看工具。
源代码深度查看工具会给团队带来不少好处，这也是JIRA，Trac，Topo等系统都都提供这个功能的原因。尽管开发人员可以通过TortoiseSVN完成几乎所有源代码深度查看工具提供的功能，但是方便性和易用性还是要差些。因为源代码深度查看分析工具都是基于WEB操作的，直接使用浏览器即可进行所有分析工作，并且提供的功能更多的是从管理的角度而不是从开发的角度设计的。

3）代码统计工具。
没有什么比一个团队连自己开发了多少代码都不知道的事情更糟糕了。一款有用的代码统计工具还是非常需要的。代码统计方面的工具也很多。
这方面的工具大概又分为几类：

•纯单机版非代码库绑定工具，需要将要统计的代码下载到本地进行比较，不支持版本间的统计对比。这类工具的鼻祖是linecounter，功能非常简洁，上手也容易。
•与代码管理工具紧密集成的客户端软件，这列软件可以与代码库链接，无需将代码下载到本地。这类工具的好处是可以直接对代码库的某个版本进行统计，并且可以分析版本间的动态变化信息。
•与代码管理工具紧密集成的web系统提供的统计，它在第2类工具的基础上提供了进一步整合，可以让所有操作全部基于浏览器进行，使用更加方便，并且更容易与项目管理系统集成或者干脆就是项目管理系统的一部分，例如Topo系统的设计。

4）代码走查或正规检视工具。
团队开展代码走查和正规检视的方式方法有很多，但是在工具支持下的这类工作更高效一些。这类工具又分为为两个子类，

•一类是帮助查错的工具，即代码扫描工具，有点类似于医院给病人看病的CT仪器，即通过代码扫描工具发现一些潜在的错误，不符合规范的隐患甚至直接找出BUG，这类工具有时又与单元测试工具又交集，例如C++ Test。
•另一类是检视过程辅助工具，最简单的是提供走查结果记录和跟踪，还有就是提供直接的在线检视，即通过与版本管理系统集成，直接提供将检视问题与代码库中的代码直接绑定，即让检视者将问题直接标识在代码行上，并提供更进一步的检视成果分析和统计功能。这类工具不多，JIRA（一般版本不提供，需要另购），Topo提供了这个支持。

5）代码持续集成工具。
持续集成是一个很好的敏捷实践，但是对所有涉及软件开发研发团队同样有效，即使你的组织采用的是基于CMMI这类重流程来说。这类工具也非常之多，免费的，商业的，开源的，Topo builder是我们公司开发的一款持续集成工具，这个工具也是免费的。

6）项目管理工具（缺陷/需求/任务/测试等）中的代码管理。
我想就是这类功能的出现造成了楼主的这个问题。这类工具提供的功能包括：一个缺陷直接与代码库中的代码关联，或者一个缺陷的解决直接与代码库中的某次代码修改关联，测试工具与代码库集成提供代码测试覆盖分析等。尽管这类功能还是非常有用的，但具有这类功能的管理系统不多，尤其是国内的项目管理系统大多不做这类“吃力不讨好的功能，因为这里涉及到一个管理系统设计理念的问题：大多数管理系统设计的出发点是管理工具而不是研发协作工具。要理解项目管理系统的这两类设计理念的差异，你可以用“JIRA/VSTS/JAZZ”和国内的多数研发管理系统的功能列表比较一下就知道了，考虑到这点，Topo在设计的考虑上更加平衡一些，即两方面都比较注重。

本文出处：杭州云图科技www.cloudtopo.com, 改善研发管理，从Topo开始！欢迎转载，但请保留此条信息.

在Topo中，要创建项目计划，首先要列出项目的主要部分，Topo中称为摘要任务，然后制订每个主要部分的次要部分（子任务），接着继续分解每个部分，直到细化到每个任务，下面按步骤一步步介绍在Topo中如何做计划管理。

创建摘要任务

1. 在“计划”页面中，单击“计划管理”。
2. 点击“开始编辑”，进入计划编辑状态。
3. 在“名称”字段中，输入第一个主要工作阶段或可交付结果的描述性名称，并估计工期。
4. 继续键入每个主要工作阶段或可交付结果的描述性名称，直到完成项目的所有摘要任务。

参考下图:

上图中的“发布 ”是一个里程碑任务，它是一个重要事件的标识，我们把它创建为里程碑任务，设置工期为0。
 

分解摘要任务

1. 选择摘要任务，在右侧为其创建子任务。
2. 为子任务分配工期，并通过工具条的缩进来指定子任务的级别。
3. 重复上述步骤，直到创建项目中的所有子任务。

输入新任务名时，Topo会自动为它们分配一天的初始工期，并将预定工期从项目开始日期当天算起。

此外，在每个主要项目结束时可以添加里程碑（重要完成点的标记）以帮助衡量项目进度和建立基点。参考下图：

注：上图中左下方五角星的图标代表关键路径，关键路径是指对项目的最终完成时间有直接影响的活动组成的路径。简单地说，就是耗时最多的活动序列组成的路径，这个标识是Topo根据任务的工期自动计算出的，不需要用户手工指定，由于还没有指定任务间的关联关系，当前显示的关键路径是不准确的。

创建任务之间的相关性

日程排定中最关键的一步就是创建任务相关性或链接 ，如果一个任务的开始或结束依赖于另一个任务的开始或结束，则存在相关性。大多数任务依赖于其他任务。在设置完相关性后，关键路径会得到准确更新。还可以轻松地更改一项任务并立即查看它对计划的其余部分所产生的连锁影响。

一般来说可以借鉴这个准则：除非任务取决于项目的开始日期，否则每个任务均具有前置任务 （前置任务：必须在另一个任务开始或完成之前开始或完成的任务）。除非任务是项目中的最后一个任务或里程碑，否则每个任务均应具有后续任务 （后续任务：在另一个任务开始或完成之后才能开始或完成的任务）。

按以下方法来设置任务间的相关性：

1. 选择需要设置前级关系的任务
2. 在“前级”这个字段中输入他的前级任务的ID（最左侧那一列的取值）。
3. 重复上述步骤，设置完成需要的所有关联关系设置。

参考下图：

上图中的关键路径任务并重新识别并出来，这些任务组成的路径就是项目计划的关键路径了。

分配资源

这时已经完成了所有任务分解工作了，然后可以为任务指定资源，在Topo中就是指定相应的执行人，按以下步骤来执行：

1. 选择需要设置资源的任务
2. 在“资源”这个字段中选择相应的执行人
3. 重复上述步骤，设置完成需要的所有任务的资源设置。

参考下图：

甘特图

甘特图（Gantt Chart）由亨利·甘特于1910年开发的，他通过条状图来显示项目、进度、和其他时间相关的计划信息，随着时间进展的情况。 其中，横轴表示时间，纵轴表示活动（项目）。制定好计划之后，就可以点击上方的“甘特图”的页面来以甘特图的方式展现计划，参考下图：

刷新进度

至此，上述的步骤已经包括了基本的计划管理的所有步骤，项目经理可以将制定好的计划下发，并随时通过甘特图来跟踪项目进展的情况。

甘特图中线条表示在整个期间上计划和实际的活动完成情况。可以直观地表明任务计划在什么时候进行，及实际进展与计划要求的对比。项目经理由此可以非常便利地弄清每一项任务还剩下哪些工作要做，并可评估工作是提前还是滞后，亦或正常进行，在项目进展过程中，任务的执行人可以随时修改任务的进展状况，参考下图：

小结

Topo提供了非常灵活而强大的计划管理工具，项目经理可以方便的制定项目完整计划，指定任务间的关联关系，Topo也会自动计算出关键路径，在计划制定并下发后，项目经理可以通过甘特图随时跟踪项目的进展情况，并对计划做出调整。

背景

1986年，竹内弘高和野中郁次郎阐述了一种新的整体性的方法 ，该方法能够提高商业新产品开发的速度和灵活性：他们将这种新的’整体性方法与橄榄球’相比较，前者各阶段相互重叠，并且由一个跨职能团队在不同的阶段完成整个过程，而后者整个团队“tries to go to the distance as a unit, passing the ball back and forth”。 他们对来自汽车，照片机器，计算机和打印机等产业的案例进行了研究。1991年，DeGrace和Stahl在《Wicked Problems, Righteous Solutions》一书中将这种方法称为 Scrum，在竹内弘高和野中郁次郎的文章中提到的橄榄球术语。1990年初，肯·施瓦伯在其公司使用了一种方法Advanced Development Methods（先进开发方法），这种方法后来发展为Scrum。同时，杰夫·萨瑟兰在Easel公司开发了一个类似的方法，并首次称之为Scrum。 1995年，在奥斯汀举办的OOPSLA ‘95上，萨瑟兰和施瓦伯联合发表了论文首次提出了Scrum概念。施瓦伯和萨瑟兰在接下的几年里合作，将上述的文章，他们的经验，以及业界的最佳实践融合起来，形成我们现在所知的Scrum。2001年，施瓦伯与麦克·比窦（Mike Beedle）合著了《敏捷软件开发-使用Scrum过程》一书，介绍了Scrum方法。

中国的软件开发群体在近几年开始使用敏捷方法，SCRUM最先在一些国内的软件公司推行，最近2年，国内的一些主流通讯设备企业也开始实施SCRUM模式，包括诺西、华为、阿朗、爱立信、UT等大公司都在研发团队中引入了SCRUM开发模式。一个最主要的原因是由传统的瀑布开发模式向敏捷转变带来客户响应效率的提升。

理念

Ø  Scrum的一个关键原则是承认客户可以在项目过程中改变主意，变更他们的需求，而预测式和计划式的方法并不能轻易地解决这种不可预见的需求变化。同 样，Scrum采用了经验方法– 承认问题无法完全理解或定义，而是关注于如何使得开发团队快速推出和响应不断出现的需求的能力最大化。

Ø  Scrum是一个包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。

Ø  在每一次冲刺（一个15到30天周期 ，长度由开发团队决定），开发团队创建可用的（可以随时推出）软件的 一个增量。每一个冲刺所要实现的特性来自产品订单（product backlog）， 产品订单是按照优先级排列的要完成的工作的概要的需求。哪些订单项会被加入一次冲刺由冲刺计划会议决定。 在会议中，产品负责人告诉开发团队他需要完成产品订单中的哪些订单项。开发团队决定在下一次冲刺中他们能够承诺完成多少订单项。 在冲刺的过程中，没有人能够变更冲刺订单（sprint backlog），这意味着在一个冲刺中需求是被冻结的。

关键知识点

1. Scrum中的角色

Scrum定义了许多角色，根据猪和鸡的笑话分为两组，猪和鸡。

猪是全身投入项目和Scrum过程的人；产品负责人代表了客户的意愿。这保证了Scrum团队做的工作从业务角度来说总是正确的事情。产品负责人编写 用户故事，排出优先级，并放入产品订单。Scrum主管（或促进者）Scrum主管促进 Scrum过 程，他的主要工作是去除那些影响团队交付冲刺目标的障碍。Scrum主管并非团队的领导（由于他们是自我组织的），而是负责屏蔽外界对开发团队的干扰。 Scrum主管确保Scrum过程按照初衷使用。Scrum主管是规则的执行者。开发团队负责交付产品的团队。由5至9名具有跨职能技能的人（设计者，开 发者等）组成的小团队完成实际的开发工作。

鸡角色并不是实际Scrum过程的一部分，但是必须考虑他们。敏捷方法的一个重要方面是使得用户和利益相关者参与到过程中的时间。参与每一个冲刺的评审和计划，并提供反馈对于这些人来说是非常重要的。

用户软件是为了某些人而创建！就像“假如森林里有一棵树倒下了，但没有人听到，那么它算发出了声音吗”，“假如软件没有被使用，那么它算是被开发出来了么？”利益所有者（客户，提供商）影响项目成功的人，但只直接参与冲刺评审过程。经理为产品开发团体架起环境的那个人。

2. Scrum会议

在冲刺中，每一天都会举行项目状况会议，被称为“scrum”或“每日站立会议”。每日站立会议有一些具体的指导原则：

会议准时开始。对于迟到者团队常常会制定惩罚措施（例如罚款，做俯卧撑，在脖子上挂橡胶玩具）欢迎所有人参加，但只有”猪”可以发言。不论团队规模大小，会议被限制在15分钟。所有出席者都应站立。（有助于保持会议简短）会议应在固定地点和每天的同一时间举行。在会议上，每个团队成员需要回答三个问题：

今天你完成了那些工作？明天你打算做什么？完成你的目标是否存在什么障碍？（Scrum主管需要记下这些障碍）每一个冲刺完成后，都会举行一次冲刺回顾会议，在会议上所有团队成员都要反思这个冲刺。举行冲刺回顾会议是为了进行持续过程改进。会议的时间限制在4小时。

Scrum提倡所有团队成员坐在一起工作，进行口头交流，以及强调项目有关的规范（disciplines），这些有助于创造自我组织的团队。

3.文档

产品订单（product backlog） 是整个项目的概要文档。产品订单包括所有所需特性的粗略的描述。产品订单是关于将要创建的什么产品。产品订单是开放的，每个人都可以编辑。产品订单包括粗 略的估算，通常以天为单位。估算将帮助产品负责人衡量时间表和优先级（例如，如果”增加拼写检查”特性的估计需要花3天或3个月，将影响产品负责人对该特 性的渴望）。

冲刺订单（sprint backlog）是大大细化了的文档，包含团队如何实现下一个冲刺的需求的信息。任务被分解为以小时为单位，没有任务可以超过16个小时。如果一个任务超过16个小时，那么它就应该被进一步分解。冲刺订单上的任务不会被分派，而是由团队成员签名认领他们喜爱的任务。

燃尽图（burn down chart）是一个公开展示的图表，显示当前冲刺中未完成的任务数目，或在冲刺订单上未完成的订单项的数目。不要把燃尽图与挣值图相混淆。燃尽图可以使’冲刺(sprint)’平稳的覆盖大部分的迭代周期，且使项目仍然在计划周期内。

Topo研发管理系统对SCRUM的支持

Topo 研发管理系统的Scrum模块为项目的多团队Scrum模式开发提供平台支持。Topo系统的Scrum模块提供团队管理、版本管理、Build管理、Sprint管理、故事管理、任务管理及缺陷管理等功能，可以全面支持团队成员按Scrum模式进行项目开发。

例如，开发人员会发现Topo为他们的工作提供了一系列的设计良好的工具支持；而研发经理们会发现他们在获取信息方面变得非常容易，并且他们的管理理念将不再只是停留在头脑中，并且管理措施的实施也能够得到很好的支持。

项目经理看到的Topo：一款高度集成的研发项目管理工具

Topo从需求分析、项目规划、到开发测试的每一阶段，都有相对完备的工具进行管理，有效地控制需求、资源、工期和质量，帮助项目团队规范和改进软件研发过程，使您的项目团队在预计周期内完成产品的开发与交付。

“你们的产品功能涵盖整个项目管理生命周期，甚至还集成了论坛、Wiki、博客等子系统。功能十分强大。尤其是：与SVN的集成以及提供管理模板的功能。给我留下了很深的印象！”

“Topo系统的需求跟踪功能非常强大，你可以看到一个需求关联的设计规格，以及这些规格关联到的开发任务以及测试用例，并且还可以看到这些测试用例的执行情况，并且还可以看到执行失败后关联到的缺陷报告。更为重要的是，这些关联都是在整个工作过程中自然而然做到的。”

“Topo系统与Microsoft Office充分集成，将我们团队已有的研发成果导入到Topo系统是何其容易！不仅需求和已有的产品设计规格书可以直接从word导入，相应的测试用例也可以从word导入，还有MS project文件也可以直接导入到Topo系统中，非常方便。”

“Topo系统在文档中实现的类似百度文库或豆丁网的文档在线查看功能非常有用，我们有一些文档并不希望项目成员保留本地备份，但是有时有需要允许他们查看，Topo可以实现在线打开查看几乎所有Microsoft Office类型文档，非常有用的功能。”

部门经理看到的Topo：一款真正支持项目和部门两个维度管理的系统

Topo系统是目前唯一真正支持项目和部门两个维度管理的系统，可以在部门下查看和统计该部门的开发人员在项目中的相关数据。部门经理将可以在部门的工作空间中，获取到部门所有成员在各个项目中的所有工作情况。

“Topo给部门管理提供了一些非常有用的功能，像绩效管理，知识管理等功能都非常完备。而且部门下的人力资源管理也非常好用，让我可以随时了解到部门开发人员在各个项目中的工作情况。”

“以前用过一些国外的设计得较好的系统，里面实现的自定义查询功能非常好用。仔细使用Topo实现的自定义查询，发现功能更加强大易用，毕竟要实现所有管理工作的任意条件的任意层次的组合查询，还是很不容易的。借助于自定义查询功能，我可以点击一下鼠标即可获得我关心的部门的所有成员的任何工作细节，非常实用的功能。”

“借助于Topo系统的自定义统计功能，基本上我想了解的任何信息都可以通过自定义统计功能实现，像部门所有成员发现的缺陷数，部门所有成员一个季度内的完成的计划任务工时情况，每个测试人员开发的测试用例数等均可以自定义统计来做到。这在其它管理系统中还没看到过，非常强大。”

开发人员看到的Topo：一个高效的研发协作及信息共享平台。

区别与大多数管理系统，Topo系统的设计充分照顾到研发人员使用Topo系统的感受，尽量通过一些良好的技术实现，让开发人员不会有 “被管理”的感觉，在系统中的一切工作都显得非常自然。

“还没见过其它系统能够像Topo一样让工作日志填写变得如此效率，你找不到任何一个工作日志系统能够像Topo系统中那样让开发人员轻松愉快地填写工作日志了，基本上就是动几下鼠标即可完成工作日志的填写。”

“非常欣赏Topo系统的’All in One’的设计理念，以前我们团队中有缺陷管理系统，测试系统，需求管理系统，任务跟踪系统，自动构建系统，大大小小的系统十几个，在这些系统中来回切换，既费时费力，且这些系统也面临无法很好地集成的问题。使用Topo后，这些独立的系统全部统一到了一个系统中，并且Topo系统提供的功能完全不弱于这些独立系统，整个开发效率得到了显著提升。”

“作为一名软件开发人员，Topo实现的标签功能非常有用，借助于标签功能，软件人员可以将代码的变化与需求，缺陷等变更原因直接关联起来，这样追溯代码的变化非常容易。”

“测试人员的痛苦在于不能及时的获知用户的需求以及系统的设计规格，在Topo系统中这些问题都不存在了，因为开发人员和测试人员在获取需求和系统规格方面得到了完全一致的信息。这样开展测试工作就会非常有目的性，并且在开发人员做编码实现时，测试人员就可以开始写测试方案，测试用例。测试人员再也不用整天去追问开发人员的实现情况了。”

IT工程师看到的Topo：一个在维护性方面考虑得非常周全的系统

无论是开源的系统还是部分商用系统，在系统的可维护性方面往往考虑得不够，导致IT维护工程师在维护系统方面面临诸多困难。Topo系统考虑到研发过程信息的重要性，在部署的方便性，运行的安全性以及可维护性方面都做了详细的考虑。

“Topo系统在实现如此多功能的情况下，本以为安装过程会非常复杂，没想到整个安装过程会如此方便，基本上就是一路next即可完成。”

“Topo支持的用户管理方案非常全面，在提供管理员创建或用户自主创建的基础上，还考虑到了与企业现有系统集成，提供了诸如Windows域/LDAP/OpenID等诸多实用的用户管理方案，考虑得非常周到。”

“喜欢Topo的一键备份功能，只需要动动鼠标，即可将Topo系统的所有数据,包括数据库，附件，文档等全量备份到一个zip包中，并且恢复Topo数据也同样容易。并且Topo系统提供了命令行备份工具，这样配合windows的计划任务，可以轻松实现Topo数据的定时备份，再也不用担心存放在Topo系统中的研发数据丢失了。”

“Topo提供的以服务方式运行的功能非常重要，并且Topo系统的运行异常自动检测及自动恢复功能也非常有用，很好的保证了Topo系统的安全运行。而且，Topo对运行时各种异常信息log记录也非常完整，这对于分析系统运行状况是否良好非常有用。”

Topo提供全功能免费试用，有兴趣的话不妨到这里申请企业版试用。

Topo为研发团队提供了一个高度整合的系统。

目前国内开发的研发管理软件，通常仅仅是一个简单的项目管理软件，只包含计划和任务管理，这对于研发型的项目管理是远远不够的，用户还需要购买需求管理软件、缺陷跟踪软件、测试管理软件、文档评审软件，才能构成一个较为完整的协作平台。

Topo系统不仅集成了需求管理、任务管理、缺陷跟踪、测试管理、文档评审、绩效管理六大模块，而且还为软件开发团队提供了代码的在线浏览和在线检视工具、构建管理工具，为硬件开发团队提供了物料管理工具，甚至还提供了一个包含文档管理、Wiki、论坛、博客在内的全功能的知识管理系统，几乎涵盖了一个研发团队需要使用的所有管理软件，是国内第一个真正意义上高度整合的研发管理系统。

使用Topo系统，企业无需再采购大量不同的研发支撑工具，研发全流程活动相关的功能都已被整合到Topo系统中，不仅可以大大降低企业的采购成本，而且各个工具之间统一的用户管理方案、统一的入口和操作界面，大大降低了软件系统的学习、使用和维护成本。

除了功能上的整合外，Topo系统的各个模块，通过丰富的对象关联和灵活易用的标签机制，从而形成统一的研发协作开发平台，可以方便的提供诸如需求的双向跟踪等高级管理功能。

Topo为研发团队提供了一个可高度定制的平台。

研发管理可能是最为复杂的管理活动，每个企业都有自己独特的管理方式。不同的团队可能需要不同的研发模型，比如有的小团队，没有专职的测试人员，可能就不需要测试管理，比如有的团队，使用敏捷开发模型，迭代周期较短，和传统的瀑布式开发就有很大的不同。

有鉴于此，Topo系统目前提供了三个项目管理模板：标准模板、轻量模板、敏捷模板。标准模板针对传统的瀑布开发模型，轻量模板针对小型研发团队，在标准模板上做了一定的简化，Scrum模板基于Scrum开发模型，为Scrum开发团队提供支持。在创建项目时，用户可以选择项目采用哪个模板进行管理。

如果用户有自己独特的研发模型，云图科技还提供了多种专业服务，可以帮助我们的客户重新定义业务流程和管理模型，实现针对客户的完全定制化的新项目管理模板。

除了定制项目管理模板外，用户还可以针对每个项目独立选择启用哪些功能模块，满足不同项目团队的需求。

Topo为矩阵管理提供了最完备的支持。

很多较大的企业会采用矩阵式管理，所谓矩阵式管理就是按照产品线和资源线两条线来组织和管理团队。产品线由开发的项目组成，比如项目1、项目2、项目3等等；而资源线按照研发人员的类型组成部门，比如软件部、硬件部、逻辑部、结构部、测试部等等。显然一个项目组需要有不同资源线部门的开发人员参与，因此在实施矩阵式管理的企业中，通常都有双向汇报机制，开发人员既要向项目经理汇报工作，又要向所属资源线部门经理汇报工作。

Topo系统是真正支持项目和部门两个维度管理的系统，可以在部门下查看和统计该部门的开发人员在项目中的相关数据。

除了支持矩阵式管理外，Topo系统还支持项目的层级化，即项目下可以建立子项目，在父项目中可以查看和统计子项目的数据，很多项目管理软件看起来可以在项目下建立子项目，但实际上在父项目中并不能查看子项目的数据。

Topo为研发管理者提供了强大的量化管理工具。

量化管理在研发管理中日益受到重视，管理者希望能方便地查看项目中的各种数据。这些数据中有些数据反映了项目的状态，比如每个月中新产生的缺陷数，可以反映项目的质量情况，管理者可以及时发现项目当中存在的问题，并采取有效措施来改善项目开发过程；有些数据可以反映开发人员的工作状态，比如每个月中解决的缺陷数，完成的任务数等等，这些数据对管理者做员工的绩效评估非常有帮助。

Topo系统针对量化管理，不仅提供了大量系统预定义的查询和统计，如每周延时和按时完成的任务、项目中未关闭的缺陷按照严重程度的分布图等，可以让用户方便地查看各种项目和个人数据，方便容易地把握项目和个人的工作状态。

更重要的是，Topo系统还提供了对查询和统计的自定义功能。再好再多的系统预定义，也很难满足用户每一个特定的数据查询需求，Topo系统是目前唯一可以支持对统计进行自定义的系统，用户可以任意设置统计的对象、统计的方法、统计的周期，并执行，还可以保存成命名统计，以备以后反复使用。该功能极大地扩展了用户获取数据的能力，为每个用户建立属于自己的量化管理模式提供了极大地帮助。

背景

1987年，美国卡内基. 梅隆大学软件研究所（SEI）受美国国防部的委托，率先在软件行业从软件过程能力的角度提出了软件过程成熟度模型（CMM），随后在全世界推广实施的一种软件评估标准，用于评价软件承包能力并帮助其改善软件质量的方法。它主要用于软件开发过程和软件开发能力的评价 和改进。它侧重于软件开发过程的管理及工程能力的提高与评估。CMM自1987年开始实施认证，现已成为软件业最权威的评估认证体系。CMM包括5个等 级，共计18个过程域，52个目标，300多个关键实践

CMMI是SEI于2000年发布的CMM的新版本。CMMI不但包括了软件开发过程改进，还包含系统集成、 软硬件采购等方面的过程改进内容。CMMI纠正了CMM存在的一些缺点，使其更加适用企业的过程改进实施。CMMI适用SCAMPI评估方法。需要注意的是，SEI没有废除CMM模型，只是停止了CMM评估方法：CBA－IPI。现在如要进行CMM评估，需使用SCAMPI方法。但CMMI模型最终代替CMM模型的趋势不可避免。

近两年来，CMM在我国获得了各界越来越多关注，业界有过多次关于CMM的讨论，2000年6月国务院颁发的《鼓励软件产业和集成电路产业发展的若干政策》对中国软件企业申请CMM认证给予了积极的支持和推动作用,第17条规定”对软件出口型企业CMM认证费用予以适当支持。总体上讲，国内对软件过程理论的讨论与实践正在展开，目标是使软件的质量管理和控制达到国际先进水平，中国的软件产业获得可持续发展的能力。

理念

Ø  CMM的基本思想是，因为问题是由我们管理软件过程的方法引起的，所以新软件技术的运用不会自动提高生产率和利润率。CMM有助于组织建立一个有规律的、成熟的软件过程。改进的过程将会生产出质量更好的软件，使更多的软件项目免受时间和费用的超支之苦。

Ø  软件过程包括各种活动、技术和用来生产软件的工具。因此，它实际上包括了软件生产的技术方面和管理方面。CMM策略力图改进软件过程的管理，而在技术上的改进是其必然的结果。

Ø  CMM强调，软件过程的改善不可能在一夜之间完成，CMM是以增量方式逐步引入变化的。CMM明确地定义了5个不同的“成熟度”等级，一个组织可按一系列小的改良性步骤向更高的成熟度等级前进。

CMM关键知识点

除第一级外，SW-CMM的每一级是按完全相同的结构构成的。每一级包含了实现这一级目标的若干关键过程域(KPA)，每个KPA进一步包含若干关键实施活动(KP)，无论哪个KPA，它们的实施活动都统一按五个公共属性进行组织，即每一个KPA都包含五类KP。

• 目标每一个KPA都确定了一组目标。若这组目标在每一个项目都能实现，则说明企业满足了该KPA的要求。若满足了一个级别的所有KPA要求，则表明达到了这个级别所要求的能力。
• 实施保证是企业为了建立和实施相应KPA所必须采取的活动，这些活动主要包括制定企业范围的政策和高层管理的责任。
• 实施能力是企业实施KPA的前提条件。企业必须采取措施，在满足了这些条件后，才有可能执行KPA的执行活动。实施能力一般包括资源保证、人员培训等内容。
• 执行过程描述了执行KPA所需求的必要角色和步骤。在五个公共属性中，执行活动是唯一与项目执行相关的属性，其余四个属性则涉及企业CMM能力基础设施的建立。执行活动一般包括计划、执行的任务、任务执行的跟踪等。
• 度量分析描述了过程的度量和度量分析要求。典型的度量和度量分析的要求是确定执行活动的状态和执行活动的有效性。

实施验证是验证执行活动是否与所建立的过程一致。实施验证涉及到管理方面的评审和 审计以及质量保证活动。在实施CMM时，可以根据企业软件过程存在问题的不同程度确定实现KPA的次序，然后按所确定次序逐步建立、实施相应过程。在执行某一个KPA时，对其目标组也可采用逐步满足的方式。过程进化和逐步走向成熟是CMM体系的宗旨。

Topo与CMM

研发管理可能是最为复杂的管理活动，每个企业都有自己独特的管理方式。不同的团队可能需要不同的研发模型，比如有的小团队，没有专职的测试人员，可能就不需要测试管理，比如有的团队，使用敏捷开发模型，迭代周期较短，和传统的瀑布式开发就有很大的不同。

无论是针对产品研发的IPD,还是针对软件开发的CMMI，SCRUM，RUP；各种与研发管理相关的方法论层出不穷。因为Topo的设计融合了这 些先进的研发管理理念和与国内最佳的研发管理实践相结合，所以学习一下这些方法论对理解Topo的设计理念并更好地使用Topo会有比较大的用处.

背景:

最先将IPD付诸实践的是IBM公司，1992年IBM在激烈的市场竞争下，遭遇到了严重的财政困难，公司销售收入停止增长，利润急剧下降。经过分 析，IBM发现他们在研发费用、研发损失费用和产品上市时间等几个方面远远落后于业界最佳。为了重新获得市场竞争优势，IBM提出了将产品上市时间压缩一半，在不影响产品开发结果的情况下，将研发费用减少一半的目标。为了达到这个目标，IBM公司率先应用了集成产品开发（IPD）的方法，在综合了许多业界 最佳实践要素的框架指导下，从流程重整和产品重整两个方面来达到缩短产品上市时间、提高产品利润、有效地进行产品开发、为顾客和股东提供更大价值的目标。

在IBM成功经验的影响下，国内外许多高科技公司采用了集成产品开发（IPD）模式，如美国波音公司和深圳华为公司等，都取得了较大的成功。实践证明，IPD既是一种先进思想，也是一种卓越的产品开发模式。

理念:

IPD作为先进的产品开发理念，其核心思想概括如下：

新产品开发是一项投资决策。IPD强调要对产品开发进行有效的投资组合分析，并在开发过程设置检查点，通过阶段性评审来决定项目是继续、暂停、终止还是改变方向。

Ø  基于市场的开发。IPD强调产品创新一定是基于市场需求和竞争分析的创新。为此，IPD把正确定义产品概念、市场需求作为流程的第一步，开始就把事情做正确。

Ø  跨部门、跨系统的协同。采用跨部门的产品开发团队（PDT：Product Development Team），通过有效的沟通、协调以及决策，达到尽快将产品推向市场的目的。

Ø  异步开发模式，也称并行工程。就是通过严密的计划、准确的接口设计，把原来的许多后续活动提前进行，这样可以缩短产品上市时间。

Ø  重用性。采用公用构建模块（CBB：Common Building Block）提高产品开发的效率。

Ø  结构化的流程。产品开发项目的相对不确定性，要求开发流程在非结构化与过于结构化之间找到平衡。

关键知识点:

• 跨部门团队，包括进行管理的产品评审委员会及具体执行开发过程的产品开发团队（PDT）。
• 结构化的流程。IPD流程分为6个阶段及4个主要决策评审点（DCP），这些阶段和决策评审点由跨部门团队进行计划和管理。6个阶段包括概念、计划、开发、验证、发布 及生命周期，每个阶段有其阶段性的目标、关注点及需交付的成果。
• 一流的子流程，包括计划与控制、阶段决策、技术评审、以用户为中心的设计、CBB-重用、文档管理、质量控制、物料管理、软硬件设计、技术管理及管道管理等。
• IPD工具：包括业务及技术上的共工具。

考评：包括团队和个人绩效考核两个方面：首先是基于产品开发团队（PDT）的指标，如上市时间（TTM）、盈利时间和公用构建模块（CBB）等；其次是基于个人的指标，包括进度或计划完成率、质量、公用构建模块、关键行为指标等。

Topo与IPD：

研发管理可能是最为复杂的管理活动，每个企业都有自己独特的管理方式。不同的团队可能需要不同的研发模型，比如有的小团队，没有专职的测试人员，可能就不需要测试管理，比如有的团队，使用敏捷开发模型，迭代周期较短，和传统的瀑布式开发就有很大的不同。

无论是针对产品研发的IPD,还是针对软件开发的CMMI，SCRUM，RUP；各种与研发管理相关的方法论层出不穷。因为Topo的设计融合了这些先进的研发管理理念和与国内最佳的研发管理实践相结合，所以学习一下这些方法论对理解Topo的设计理念并更好地使用Topo会有比较大的用处.

在我看来，一个Bug系统应该更加全面，管理Bug的生命周期的同时，也用于管理一个产品、团队的知识，更可以与周边系统合作，形成一个真正的集成式管理平台。

Bug的分类

现在的Bug系统，对Bug系统的分类通常有这么几种：

• 根据性质：Bug、Feature、Enhancement等。
• 根据危险程度：Trival、Minor、Normal、Major、Critical等。
• 根据模块、系统、可重现性等与项目紧密相关的分类。

但是这些Bug系统往往忽略了一个很重要的分类方式，那就是“按Bug影响面分类”，在这种分类模式下，一个Bug可以根据其影响的范围来进行区分：

项目型Bug

与当前项目的业务流程、逻辑等有紧密关系的Bug，此类Bug只可能在当前项目中出现，离开了项目的大环境就没有任何存在的意义。

针对此类的Bug，只需要在当前的环境下修复即可，不需要考虑太多的问题。

复发型Bug

此类Bug通常也与项目有紧密的关系，但是此类Bug在项目的整个演化过程中一而再再而三的出现，也许每一次出现的原因有些许差异，但表现上极其相似。比如某系统每天下午17：00左右会出现无法提供服务的情况，在第一轮修复的情况下，几周后继续出现此类情况。

在这样的前提下，该问题就应该被评定为复发型Bug。对于复发型Bug，项目管理层及开发人员都应该给予绝对的重视，投入足够的人力和时间来对问题进行彻底的跟踪和追查，以期从根本上进行解决。

同时，在问题被定位并修复后，可以进行一次case study，以杜绝此类问题的再次发生。

通用型Bug

此类Bug是我认为当前的Bug系统最没有关注到的一个问题，而且相比前面两类Bug往往可以在项目层面通过制度和流程来进行规范，通用型Bug是一个最需要自动化处理的问题。这往往涉及到不同团队之间的合作，也是Bug平台成为一个知识库的最为基础的条件。

顾名思义，通用型Bug即与项目本身的业务没有任何关系的，仅仅是技术上存在的问题。比如我最近发现的一个Bug，其可以用以下的代码来表现：

<!DOCTYPE html>
<head>
    <base target="_blank" />
<body>
    <script>
        var iframe = document.createElement('iframe');
        document.body.appendChild(iframe);
        iframe.contentWindow.location = 'javascript:;';
        // 以上代码会在IE9下弹出一个窗口
    </script>

这个Bug很明显，是不属于任何项目的，即所有项目在特定的情况下都可能使用类似的代码，产生相同的Bug。

在这样的情况下，如果将这个Bug继续划定在某个项目之下，那么他最多只能为一个项目提供帮助，防止该项目再次出现类似的问题。因此我们各项目组间可能经常能看到这样的对话：

A：Hi，我们这边发现一个问题，具体是…………这样的，你们有相关经验吗？

B：哈哈，这个我们前段时间才遇上过，解决方法是…………那样的。

A：谢谢，谢谢！！

确实，这样的场景很多，甚至能贯以“项目之间善于交流”的美名，但是如果认真地去思考，这样的场景真的有必要吗？如果有一个自动化的平台，会将这些通用的Bug都公布出来，每个人各取所需进行关注、记录，又怎么会出现这样的对话呢？

交流，哪怕是使用最好的方式进行最有效的沟通，始终是有一定的成本的。同时，交流通常是1v1的关系，即便频繁的接触、沟通，一个知识也很难以广播的形式让尽可能多地需要他的人接收到。

正因如此，我才认为一个Bug系统的职责远不止记录、处理、关闭Bug，而应该作为一个知识的集散地，在团队的发展中起更大的作用。

通用性Bug处理平台

前面也提到，对于通用型Bug，平台应该有能力对其进行分发、通告，在这里再详细地总结一下，一个较为完善的Bug平台，在处理通用型Bug方面应该至少有以下的特色：

Bug的tag

无论系统内置使用怎么样的方式来对Bug进行分类，其分类的维度总会有照顾不周之处。因此在Bug平台中应该引入tag的概念，让每一个Bug都能够有一个或多个tag，使用tag这种通用的方式来标识一个Bug的属性，也进一步方便了灵活的分类。

Bug的订阅

在Bug有了tag之后，所有拥有相应权限的人都可以订阅其指定的tag的通用型Bug。当一个Bug被提升为通用型Bug时，Bug平台会找到 所有订阅了这个Bug拥有的tag的用户，并通过邮件等形式向其发送该Bug报告。而随后Bug的每一个处理环节都会有邮件等形式的广播。

Bug的共享

在Bug可以被订阅和广播的同时，通用型Bug应该允许每一个有权限（并且此类权限应该放得很宽松）的用户来参与讨论、修补，每一个人都可以提交 解决方案，再由相应的QA进行验证后给予实行。这样的效率远大于一个项目的开发人员独自苦苦挣扎，因为很可能有某个人曾经遇上过这个问题，对他来说提供解 决方案仅仅是举手之劳。

Bug的生命周期

当前多数的Bug平台将Bug的状态分为几个阶段，一般是Open -> Resolved -> Closed这样的过程，但这其实远远没有涵盖一个Bug处理过程中应该有的环节。

当然作为一个简单、现实为上的Bug系统，其主要环节有以上三者足矣，但是如果需要将Bug平台扩展成一个知识库，就不得不添加更多的环节，以期得到更多的信息：

1. Open，Bug的发现阶段，此时创建一个Bug，通常这个动作由QA进行。任何可重现、不可重现、小频率重现的问题都可以进入到这个阶段。
2. Reproduce Step Confirmed，Bug的重现步骤被确定，通常由QA提交。在这个阶段的Bug通常是稳定的，至少通过QA提供的重现步骤能大概率地被重现出来。
3. Reproduce Environment Confirmed，Bug的重现环境被确定，通常由开发人员提交。在这个阶段，在正常的重现步骤之外，开发人员已经可以提供一个最简的环境来复现问题， 可能是一段非常精简的代码，也可能是一个很简单的步骤，其特点是这个重现的环境远比QA的按步操作来得简单，甚至可能得以自动化的重现。如果问题可以自动 化重现和确定，则可以考虑将自动化脚本作为单元测试保存。
4. Reason Found，问题的根本原因被确定，通常由开发人员提交。在这个阶段，开发人员需要描述问题产生的原因，可能是某个业务逻辑的理解有分歧、或者某个第三方产品确实存在Bug、或者某段代码存在着函数使用的错误等。
5. Resolution Submitted，解决方案已提交，通常由开发人员进行。在这个阶段，开发人员提交一个完整的解决方案，根据开发人员的思路，这个解决方案确实得以修复该问题。随后同项目级的人员、QA可以对该解决方案进行评估，确定对其他模块不会有影响等。
6. Resolution Applied，已经应用了解决方案，通常由开发人员提交。此时开发人员指定一个新的源码版本号，该版本号中的相应代码段应用了第5步中提交的解决方案，问题应当已经修复。
7. Resolution Confirmed，问题已经确定修复，由QA人员提交。此阶段QA确定问题已经被修复，并且经过了一定范围的回归测试，确保问题不会对其他模块产生严重影响。在这个阶段，Bug依旧是开放状态，各成员可以对Bug进行参与，作一些总结性的讨论。
8. Close，Bug关闭，此时Bug已经锁定，可以作为一个固定的知识项来查看，但不再有修改和讨论的可能性。

以上为一个非常周全的Bug生命周期管理，但确实不需要对其进行一个强制的要求。一个Bug平台可以提供这些生命周期，也许只是简单地在“Bug状 态”中添加相应的项，而进一步如何引导用户对这些环节进行充分的利用，则可以通过团队的规章、Bug平台本身的界面等方面来进行，强硬地规定只会让Bug 追踪过程事倍功半。

其他方面的增强

上文提的是个人认为Bug平台向知识库整合过程中最重要的一环，即通用型Bug的分类、分享、订阅工作，以此为其他来散布众多点状知识，以期通过所有人员共同参与交流、沟通，再将点状的知识整合成线状甚至是面状的知识体系，补充团队的经验和能力。

但是在此之外，其实Bug平台还可以做很多事情，来提高这个“伪知识平台”的使用体验，证知识更加有条理、有结构：

• 与源码平台关联

  一个Bug平台应该与源码平台有着非常紧密的关系，包括一个Bug在哪个版本（A）发现，在哪个版本（B）修复，并可以通过平台找到源码平台中两个 版本的diff，比如scm.xxx.com/diff?file=abc&rev=A:B。这要求Bug平台与源码平台都提供相应的接口，可以 在两个第三方系统间进行交互合作，现时也要求Bug平台有一个严格的规范，在Bug的open和close操作中提供相关的版本号。

• 与知识平台关联

  Bug是知识的来源，那么Bug提供的知识自然要进入到知识管理平台。这一点需要系统的智能化识别，当一个Bug其信息足够完善，包括了前面提到的 Bug生命周期的各个环节应有的信息的时候，Bug平台应该主动与知识平台连接，将这个Bug整理成一份真正的知识文档进入到知识管理平台。

层级结构的数据保存在平面的数据库中基本上有三种常用设计方法：

1、毗邻目录模式(adjacency list model)

2、预排序遍历树算法(modified preorder tree traversal algorithm)

这里我用一个简单食品目录作为我们的示例数据。

我们的数据结构是这样的：

以下是代码：
[code:1:86c003e7bb]
Food
|
|---Fruit
| |
| |---Red
| | |
| | |--Cherry
| |
| |---Yellow
| |
| |--Banana
|
|---Meat
|
|--Beef
|
|--Pork
[/code:1:86c003e7bb]

为了照顾那些英文一塌糊涂的PHP爱好者
Food:食物
Fruit:水果
Red:红色
Cherry:樱桃
Yellow:黄色
Banana:香蕉
Meat:肉类
Beef:牛肉
Pork:猪肉

一：毗邻目录模式(adjacency list model)
这种模式我们经常用到，很多的教程和书中也介绍过。我们通过给每个节点增加一个属性 parent 来表示这个节点的父节点从而将整个树状结构通过平面的表描述出来。根据这个原则，例子中的数据可以转化成如下的表：

以下是代码：
[code:1:86c003e7bb]
+-----------------------+
| parent | name |
+-----------------------+
| | Food |
| Food | Fruit |
| Fruit | Green |
| Green | Pear |
| Fruit | Red |
| Red | Cherry |
| Fruit | Yellow |
| Yellow| Banana |
| Food | Meat |
| Meat | Beef |
| Meat | Pork |
+-----------------------+
[/code:1:86c003e7bb]

我们看到 Pear 是Green的一个子节点，Green是Fruit的一个子节点。而根节点'Food'没有父节点。 为了简单地描述这个问题， 这个例子中只用了name来表示一个记录。 在实际的数据库中，你需要用数字的id来标示每个节点，数据库的表结构大概应该像这样：id, parent_id, name, description。
有了这样的表我们就可以通过数据库保存整个多级树状结构了。

显示多级树
如果我们需要显示这样的一个多级结构需要一个递归函数。

以下是代码：
[code:1:86c003e7bb]
// $parent is the parent of the children we want to see
// $level is increased when we go deeper into the tree,
// used to display a nice indented tree

function display_children($parent, $level)
{
// 获得一个 父节点 $parent 的所有子节点
$result = mysql_query('SELECT name FROM tree '.
'WHERE parent="'.$parent.'";');

// 显示每个子节点
while ($row = mysql_fetch_array($result))
{
// 缩进显示节点名称
echo str_repeat(' ',$level).$row['name']."n";

//再次调用这个函数显示子节点的子节点

display_children($row['name'], $level+1);
}
}
?>
[/code:1:86c003e7bb]

对整个结构的根节点（Food）使用这个函数就可以打印出整个多级树结构，由于Food是根节点它的父节点是空的，所以这样调用: display_children('',0)。将显示整个树的内容：
[code:1:86c003e7bb]
Food
Fruit
Red
Cherry
Yellow
Banana
Meat
Beef
Pork
[/code:1:86c003e7bb]
如果你只想显示整个结构中的一部分，比如说水果部分，就可以这样调用：display_children('Fruit',0);

几乎使用同样的方法我们可以知道从根节点到任意节点的路径。比如 Cherry 的路径是　"Food > Fruit > Red"。 为了得到这样的一个路径我们需要从最深的一级"Cherry"开始， 查询得到它的父节点"Red"把它添加到路径中， 然后我们再查询Red的父节点并把它也添加到路径中，以此类推直到最高层的"Food"

以下是代码：
[code:1:86c003e7bb]
// $node 是那个最深的节点
function get_path($node)
{
// 查询这个节点的父节点
$result = mysql_query('SELECT parent FROM tree '.
'WHERE name="'.$node.'";');
$row = mysql_fetch_array($result);

// 用一个数组保存路径
$path = array();

// 如果不是根节点则继续向上查询
// (根节点没有父节点)
if ($row['parent']!='')
{
// the last part of the path to $node, is the name
// of the parent of $node
$path[] = $row['parent'];

// we should add the path to the parent of this node
// to the path
$path = array_merge(get_path($row['parent']), $path);
}

// return the path
return $path;
}
?>
[/code:1:86c003e7bb]

如果对"Cherry"使用这个函数：print_r(get_path('Cherry'))，就会得到这样的一个数组了：
[code:1:86c003e7bb]
Array
(
[0] => Food
[1] => Fruit
[2] => Red
)
[/code:1:86c003e7bb]
接下来如何把它打印成你希望的格式，就是你的事情了。

缺点：
这种方法很简单，容易理解，好上手。但是也有一些缺点。主要是因为运行速度很慢，由于得到每个节点都需要进行数据库查询，数据量大的时候要进行很多查询才能完成一个树。另外由于要进行递归运算，递归的每一级都需要占用一些内存所以在空间利用上效率也比较低。

二：预排序遍历树算法
现在让我们看一看另外一种不使用递归计算，更加快速的方法，这就是预排序遍历树算法(modified preorder tree traversal algorithm)
这种方法大家可能接触的比较少，初次使用也不像上面的方法容易理解，但是由于这种方法不使用递归查询算法，有更高的查询效率。

我们首先将多级数据按照下面的方式画在纸上，在根节点Food的左侧写上 1 然后沿着这个树继续向下 在 Fruit 的左侧写上 2 然后继续前进，沿着整个树的边缘给每一个节点都标上左侧和右侧的数字。最后一个数字是标在Food 右侧的 18。 在下面的这张图中你可以看到整个标好了数字的多级结构。（没有看懂？用你的手指指着数字从1数到18就明白怎么回事了。还不明白，再数一遍，注意移动你的手指）。
这些数字标明了各个节点之间的关系，"Red"的号是3和6，它是 "Food" 1-18 的子孙节点。 同样，我们可以看到 所有左值大于2和右值小于11的节点 都是"Fruit" 2-11 的子孙节点

以下是代码：
[code:1:86c003e7bb]
1 Food 18
|
+-------------------------------------------+
| |
2 Fruit 11 12 Meat 17
| |
+------------------------+ +-----------------------+
| | | |
3 Red 6 7 Yellow 10 13 Beef 14 15 Pork 16
| |
4 Cherry 5 8 Banana 9
[/code:1:86c003e7bb]

这样整个树状结构可以通过左右值来存储到数据库中。继续之前，我们看一看下面整理过的数据表。

以下是代码：
[code:1:86c003e7bb]
+-----------------------+-----+-----+
| parent | name | lft | rgt |
+-----------------------+-----+-----+
| | Food | 1 | 18 |
| Food | Fruit | 2 | 11 |
| Fruit | Red | 3 | 6 |
| Red | Cherry | 4 | 5 |
| Fruit | Yellow | 7 | 10 |
| Yellow | Banana | 8 | 9 |
| Food | Meat | 12 | 17 |
| Meat | Beef | 13 | 14 |
| Meat | Pork | 15 | 16 |
+-----------------------+-----+-----+
[/code:1:86c003e7bb]
注意：由于"left"和"right"在 SQL中有特殊的意义，所以我们需要用"lft"和"rgt"来表示左右字段。 另外这种结构中不再需要"parent"字段来表示树状结构。也就是 说下面这样的表结构就足够了。

以下是代码：
[code:1:86c003e7bb]
+------------+-----+-----+
| name | lft | rgt |
+------------+-----+-----+
| Food | 1 | 18 |
| Fruit | 2 | 11 |
| Red | 3 | 6 |
| Cherry | 4 | 5 |
| Yellow | 7 | 10 |
| Banana | 8 | 9 |
| Meat | 12 | 17 |
| Beef | 13 | 14 |
| Pork | 15 | 16 |
+------------+-----+-----+
[/code:1:86c003e7bb]

好了我们现在可以从数据库中获取数据了，例如我们需要得到"Fruit"项下的所有所有节点就可以这样写查询语句：
SELECT * FROM tree WHERE lft BETWEEN 2 AND 11;
这个查询得到了以下的结果。

以下是代码：
[code:1:86c003e7bb]
+------------+-----+-----+
| name | lft | rgt |
+------------+-----+-----+
| Fruit | 2 | 11 |
| Red | 3 | 6 |
| Cherry | 4 | 5 |
| Yellow | 7 | 10 |
| Banana | 8 | 9 |
+------------+-----+-----+
[/code:1:86c003e7bb]

看到了吧，只要一个查询就可以得到所有这些节点。为了能够像上面的递归函数那样显示整个树状结构，我们还需要对这样的查询进行排序。用节点的左值进行排序：

SELECT * FROM tree WHERE lft BETWEEN 2 AND 11 ORDER BY lft ASC;

剩下的问题如何显示层级的缩进了。

以下是代码：
[code:1:86c003e7bb]
function display_tree($root)
{
// 得到根节点的左右值
$result = mysql_query('SELECT lft, rgt FROM tree '.'WHERE name="'.$root.'";');
$row = mysql_fetch_array($result);

// 准备一个空的右值堆栈
$right = array();

// 获得根基点的所有子孙节点
$result = mysql_query('SELECT name, lft, rgt FROM tree '.
'WHERE lft BETWEEN '.$row['lft'].' AND '.
$row['rgt'].' ORDER BY lft ASC;');

// 显示每一行
while ($row = mysql_fetch_array($result))
{
// only check stack if there is one
if (count($right)>0)
{
// 检查我们是否应该将节点移出堆栈
while ($right[count($right)-1]<$row['rgt'])
{
array_pop($right);
}
}

// 缩进显示节点的名称
echo str_repeat(' ',count($right)).$row['name']."n";

// 将这个节点加入到堆栈中
$right[] = $row['rgt'];
}
}
?>
[/code:1:86c003e7bb]

如果你运行一下以上的函数就会得到和递归函数一样的结果。只是我们的这个新的函数可能会更快一些，因为只有2次数据库查询。

要获知一个节点的路径就更简单了，如果我们想知道Cherry 的路径就利用它的左右值4和5来做一个查询。

SELECT name FROM tree WHERE lft < 4 AND rgt > 5 ORDER BY lft ASC;

这样就会得到以下的结果：

以下是代码：
[code:1:86c003e7bb]
+------------+
| name |
+------------+
| Food |
| Fruit |
| Red |
+------------+
[/code:1:86c003e7bb]

那么某个节点到底有多少子孙节点呢？很简单，子孙总数=(右值-左值-1)/2
descendants = (right – left - 1) / 2
不相信？自己算一算啦。
用这个简单的公式，我们可以很快的算出"Fruit 2-11"节点有4个子孙节点，而"Banana 8-9"节点没有子孙节点，也就是说它不是一个父节点了。

很神奇吧？虽然我已经多次用过这个方法，但是每次这样做的时候还是感到很神奇。

这的确是个很好的办法，但是有什么办法能够帮我们建立这样有左右值的数据表呢？这里再介绍一个函数给大家，这个函数可以将name和parent结构的表自动转换成带有左右值的数据表。

以下是代码：
[code:1:86c003e7bb]
function rebuild_tree($parent, $left) {
// the right value of this node is the left value + 1
$right = $left+1;

// get all children of this node
$result = mysql_query('SELECT name FROM tree '.
'WHERE parent="'.$parent.'";');
while ($row = mysql_fetch_array($result)) {
// recursive execution of this function for each
// child of this node
// $right is the current right value, which is
// incremented by the rebuild_tree function
$right = rebuild_tree($row['name'], $right);
}

// we've got the left value, and now that we've processed
// the children of this node we also know the right value
mysql_query('UPDATE tree SET lft='.$left.', rgt='.
$right.' WHERE name="'.$parent.'";');

// return the right value of this node + 1
return $right+1;
}
?>
[/code:1:86c003e7bb]

当然这个函数是一个递归函数，我们需要从根节点开始运行这个函数来重建一个带有左右值的树

rebuild_tree('Food',1);

这个函数看上去有些复杂，但是它的作用和手工对表进行编号一样，就是将立体多层结构的转换成一个带有左右值的数据表。

那么对于这样的结构我们该如何增加，更新和删除一个节点呢？

增加一个节点一般有两种方法：

第一种，保留原有的name 和parent结构，用老方法向数据中添加数据，每增加一条数据以后使用rebuild_tree函数对整个结构重新进行一次编号。

第二种，效率更高的办法是改变所有位于新节点右侧的数值。举例来说：我们想增加一种新的水果"Strawberry"（草莓）它将成为"Red"节点的最后一个子节点。首先我们需要为它腾出一些空间。"Red"的右值应当从6改成8，"Yellow 7-10 "的左右值则应当改成 9-12。 依次类推我们可以得知，如果要给新的值腾出空间需要给所有左右值大于5的节点 （5 是"Red"最后一个子节点的右值） 加上2。 所以我们这样进行数据库操作：

UPDATE tree SET rgt=rgt+2 WHERE rgt>5;
UPDATE tree SET lft=lft+2 WHERE lft>5;

这样就为新插入的值腾出了空间，现在可以在腾出的空间里建立一个新的数据节点了， 它的左右值分别是6和7

INSERT INTO tree SET lft=6, rgt=7, name='Strawberry';

再做一次查询看看吧！怎么样？很快吧。

好了，现在你可以用两种不同的方法设计你的多级数据库结构了，采用何种方式完全取决于你个人的判断，但是对于层次多数量大的结构我更喜欢第二种方法。如果查询量较小但是需要频繁添加和更新的数据，则第一种方法更为简便。

另外，如果数据库支持的话 你还可以将rebuild_tree()和 腾出空间的操作写成数据库端的触发器函数， 在插入和更新的时候自动执行， 这样可以得到更好的运行效率， 而且你添加新节点的SQL语句会变得更加简单。

三：说明
该篇文章中整理自互联网，这些内容有些细节讲得也不够清楚，不过对于有数据库树状结构设计任务的开发人员来说，读下来至少有一个思路，其实按照这些思路实现相应程序应该并不困难，希望对你同样能够有所帮助。

据他介绍，他当下所在的公司研发人员大概20人多人，公司加班比较严重；工作基本上是早上8:30到晚上8:30，而且他们几乎每个周六都要加班。作为测试人员的他经常被项目经理临时要求加班，几乎每天下午5：30左右，项目经理就会安排一些“突发”的任务给他们，让他们晚上把这些任务完成了才走；当然开发人员加班比他们还要晚。

读到这里，你可能已经感觉到这是一家公司正处于上升期，业务蒸蒸日上的公司。没错，听这位测试员工的描述，公司的产品尽管还有不少待完善的地方，但是市场要得比较急，研发正为满足市场需求和业务拓展而疲于奔命。按理说，在这家公司的员工应该能够感觉到工作比较充实，并且研发能力提升也比较快才对，但是这个员工的离职理由却是：受不了经常加班，并且感觉个人能力提升较慢，用他的话就是整天干的是做牛做马的活，但收入也就那么一点点；而且他说，团队中已经有不少研发人员准备离开了。问他加班有加班工资吗？他说有的，不过工资本来就不高，就算加上加班工资（全部算上也就3K多点），去掉一般开销，1个月下来也就所剩无几了。

这是他描述的测试工作开展的情况：“我们会在EXCEL中列举一下测试项，一般是功能性测试和一些异常测试，然后在WORD文档中描述一下这些测试项的大致的测试方法。然后按照这些测试文档开展测试，刚进公司前几个月时，如果测试发现问题的话，我们会叫研发人员来看，后来因为问题实在太多，项目经理就让我们将问题记录在EXCEL中，到周末时集中将问题反馈给开发人员，有时开发人员忙不过来，就可能2周汇总一次问题；后来我们反馈很多测试出的问题开发都没解决和反馈结果，经讨论将这个过程改成：在论坛中发帖记录测试出现的问题，然后开发人员在论坛中回帖告知问题有没有解决，这样测试就知道这些问题的解决进展了。然后我们根据论坛中研发人员的回帖，我们会整理一下论坛中的问题，并记录在一个excel中，并根据开发人员在论坛中的回帖刷新这些问题的解决状态，这样做后感觉有序多了。”

总结一下他们的工作过程就是：“用excel来记录问题，用论坛来协同工作”，而且这还是一个刚毕业1年的新人给项目经理建议下才做到的。问为何不考虑用一些缺陷管理工具呢？他一脸茫然，好像不知道我在说啥！都什么年代了，还停留在用excel跟踪问题的原始阶段。在研发团队中启用缺陷管理工具，这已经是一个最低要求了，随便找找，免费的，开源的系统一抓一大把，这些系统真的就那么难于使用吗？还是这些项目经理根本就觉得让开发人员低效率的工作本身对他们来说就是一种享受？！我们公司在推广TOPO研发管理系统免费版时给所有免费版客户承诺，提供全面的技术支持服务，从QQ群、远程协作、EMAIL、电话等，但是，仍然有这么多公司还停留在刀耕火种的石器时代，既可悲更可叹！

项目经理让开发人员加班没错，但是如以为公司给开发人员支付了加班工资就理所当然则很不应该。其实，让开发人员高效率的工作，把他们的旺盛精力（那怕是加班）投入到最能给公司带来价值的工作上，才是项目经理最应该做的，否则，你浪费的绝对不仅仅是公司支付给员工的那点加班费，更多的是在浪费他们的生命。（也许说得有些严重，但道理如此）

如果你的研发团队连最起码的缺陷管理系统都没有的话，我建议您立即动手，为团队搭建一套这样的系统，如果你的项目经理不支持你这样做，那么你还是离开这个公司吧，研发人员的黄金工作年限也就那么三五年，别把你的宝贵青春浪费到这种低效率的工作团队中。

作为本文的结束，这里给各公司的运用管理工具的水平来做个分级，不妨研究一下你的公司的研发水平处于何种档次：

在当前国内实际的大环境下，要找一个不加班的研发团队的确比较困难，笔者并不反对加班，但是比起如何督促开发人员低效率的加班，研发管理者特别是项目经理还有更多值得仔细思考的地方。作为研发管理者的你对“如何让研发人员的工作更高效些？”这个问题都没有仔细思考过，很难说你是称职的。

本文版权归杭州云图科技有限公司所有，欢迎完整转载，但请保留该版权声明.

下载Topo研发管理系统项目经理手册 (1363).

• 需求，任务，缺陷等均提供文件上传支持;
• 更换服务器地址后，Topo服务器富文本编辑上传的图片不会受服务器地址变化的影响;
• 完善了topo-setup功能，使其支持完全的数据备份和恢复，并提供topo服务的菜单控制（增加，删除，启停）功能;
• 增强数据库导出功能，使其能够将导出的二进制数据转换成文本数据。

详细的升级指导参见“Topo研发管理系统免费版V3.1.5537升级指南”

如果你是第一次使用Topo免费版，推荐您下载这份资料：TOPO研发管理系统免费版V3.1安装使用指南 (49455)

截止到2011年4月15日，Topo研发管理系统免费版下载量已达7768次，望广大Topo免费版客户及时更新到最新版本。如果您正在为您的团队寻找一款一站式全功能集成的研发管理系统，不妨关注一下Topo。

1：备份5105的数据。

• 为防止升级过程中误操作导致数据丢失，请使用topo_setup.bat中的备份功能，备份一下topo5105版本的数据。

2：停止运行Topo5105版本。

• 如果以服务方式运行的，请停止掉topo服务；
• 如果是以DOS窗口方式运行的，直接关闭掉该窗口即可。

3：下载并安装在一个全新的目录下安装V3.1.5537版本。

• 从这里下载最新的版本；
• 安装时可以使用5105版本的license，数据库可以直接设置为5105原来的数据库，如果没有license，可以到这里申请。

4：第一次启停新版本。

启动V3.1.5537，V3.1.5537新版本会自动完整一些数据库字段的升级更新工作。

确认V3.1.5537版本正常启动，这时访问Topo仍然有一个功能是不正常的，还需要经过步骤5来手工修正一下数据库，先停止掉Topo。

5：使用数据库工具MySQL GUI Tools，更新下列三个数据库的设置。

• 需要调整的数据库表有：os_currentstep，os_historystep，os_wfentry
• 将上面三个表的ID字段属性设置成“auto inc“

具体操作方法如下：

• 如果没有MySQL GUI Tools，推荐到这里下载。
• 运行MySQL GUI Tools,然后按照下列指示的方法修改

1:找到os_currentstep

2:将ID字段的auto inc属性设置选项勾选上,如下图所示：

然后保存即可，使用同样的方法，更改另外两张数据库os_historystep，os_wfentry。

6：启动新的Topo服务器，完成整个升级过程.

如果在升级和使用过程中遇到任何问题，欢迎与云图科技技术支持团队联系：QQ:744867432

或者，等价的说，“同步”=“删除” + “拷贝”。

Robocopy

Robocopy是Windows命令行下的一个增强拷贝工具，它支持同步两个目录，可以这样用：

robocopy src dst /MIR

/MIR就表示使用同步模式，这样就可以将源目录src同步到目标目录dst了。

安装

Robocopy在Windows7、Windows Vista、Windows 2008 Server下，是内置的，但在Windows XP、Windows 2003 Server这些较老的系统中，robocopy是没有的，需要从Windows Resource Kit中拷贝一下。

排除文件

某些时候，我们希望某些目录，不需要同步。 比如，在软件开发中如果用到svn，那么通常.svn目录是不希望同步的，可以用/XD参数来排除这些文件和目录，这样设置就可以了：

robocopy src dst /MIR /XD .svn

缺陷

robocopy在大部分情况下工作很好，并且速度快，不过Windows下，由于Windows文件系统不区分大小写，robocopy不能保证文件名的大小写被正确同步。

比如，源目录下有个文件叫做readme.txt，目标目录下有个文件叫做 Readme.txt，robocopy可以保证他们被同步，内容同步正确，但同步之后，目标目录下的文件仍叫做 Readme.txt，而不是readme.txt。

大部分情况下，这个大小写未同步不会造成问题，因为Windows文件系统本来就不区分大小，但在某些情况下，比如要将目录打包到Linux，或Java下使用，就可能造成文件找不到的问题。

Linux

在Linux系统下，我们有更好用且强大的rsync，所以就无需robocopy了。

市场上的文档管理软件很多，但作为企业级的文档管理软件，除了简单的集中存储文档外，还可以帮助企业保障文档安全，积累知识经验，提升文档知识使用效率，降低文档知识流失风险。企业级文档管理软件协助企业更高效地管理企业文档，全面规范企业知识管理，并以此为基础实现团队效率的提升。

企业级文档管理软件至少要具备下面的几个特性:

• 文档可以清晰、独立授权。
• 文档可以有版本，可以为文档保存多个版本。
• 文档可以做全文索性，以支持全文检索。
• 支持文档多种访问方式，比如Web、WebDAV、Ftp等。

M-Files

M-Files的文档管理软件，除了上面提到的功能外，还可以支持文档的check-out和check-in（类似一些源代码控制工具的版本控制）。

ITAZ Globodox

Globodox除了手工添加文档到文档库，还可以自动做文档的OCR，这样的话，扫描的文档，也可以被搜索了。

Dokmee

Dokmee提供多种版本，其中企业版本提供了上述的基本功能。

Topo

Topo项目管理软件集成了完整的企业文档管理功能，除了上述的基本功能外，还支持和Word集成的文档评审，以及文档的在线查看。文档评审和Word集成，可以完整解决企业的文档评审问题。文档在线查看，可以方便保存不同格式的文件，这样用户无需安装专门的客户端软件，就可以在线浏览文档内容了。

研发战略和规划是公司战略在市场和产品领域的具体体现，是公司对产品机遇的战略性认识，包括产品战略愿景、产品平台战略及规划、产品线战略及规划、具体产品的开发计划四个层次。

国内企业一般会有一个远大的产品发展目标，也制定具体的产品开发计划，但很少在产品平台战略和产品线规划上下功夫。缺乏明确和前瞻性的产品平台规划和产品线规划，产品开发就失去了路线图，产品开发人员就会无章可循，他们会在不知该产品在公司未来规划中所处位置的情况下，定义和开发产品。其结果是，各个产品相互拼凑，不能形成一条一体化的产品线。而企业由于不能按恰当顺序开发并投放新产品，往往错失良机，在恼怒的心态下，于是企图样样都一下子做出来，结果摊子铺得太大，而发现自己不具备充足的资源。

跨部门协作困难

产品开发是一项综合性的活动，几乎需要企业所有的职能都参与进去。也正是在各职能参与到产品开发过程中，带来了部门协作和协调困难的种种问题，这些问题几乎出现在所有的国内企业，不管他们在组织方式上是采用项目结构、职能结构还是矩阵结构。

首先，各部门对产品开发的成功标准缺乏一致的认识。比如技术部门认为只要产品顺利转入中试就成功了，制造部门理解的成功则是产品制造流程和工艺的稳定，而市场部门则关注的产品何时上市、销量如何。各部门在产品开发过程中缺乏一致的目标是带来跨部门协作困难的根源之一。更有甚者，产品开发被认为只是研发部门的事，其它部门只是义务配合一下，这与产品开发活动的本质就相差太远了。

其次，在项目运作层面没有有效的运作原则和机制。绝大多数的企业都会采用项目组的方式来负责产品开发。但是，真正有责有权、运作高效的项目组少之又少。更多的情况是，项目经理的角色更象是一个行政管理人员、记录人员和协调人员，而不是领导者，项目组并不是真正的跨部门小组，职能部门所拥有的权利和责任比开发组多，责任的划分模糊。一旦出了问题，部门之间就相互抱怨及推诿责任。

另外，跨部门协作的障碍也来自于文化的不支持。很多公司习惯于做事情各自为政，本位主义和官僚主义较严重，属于跨部门协作的”土壤”不良。

缺乏有效结构化的产品开发流程和项目管理，产品质量管理尤其薄弱

很多公司制定了产品开发流程，但它们的流程只是一些功能流程(如硬件开发流程、测试流程)的集合，而缺乏一个联合了所有的职能部门的集成的总体流程，这就象作战时缺乏总体的”作战地图”和”作战方案”，导致项目组如何开展工作，各部门如何参与到产品开发过程中缺乏统一部署和安排，只能到时候各行其是。流程层次不清、不够规范、不具体、不细化、操作性不强等结构化不足的问题在国内企业中也非常突出，加之跨部门协作的机制又不强，导致产品开发流程在”部门墙”林立的情景下运行艰难、接口不畅、漏洞百出。

国内企业研发流程的另外一个典型问题是，在产品开发前面的阶段，除了技术部门以外，测试、制造、维护、财务，甚至市场部门很少参与，导致产品开发偏重从技术的角度来考虑问题，产品的可制造性、可靠性、可测试性、可维护性等方面的需求考虑很少，导致产品开发后面的阶段要花大量的时间和精力来修改前期考虑不周的错误，甚至要重新设计。

尽管，项目管理的方法和工具在国内企业已经开始普及，但由于相配套的组织机制、业务流程、考评激励措施欠缺，项目管理的有效性也是比较差的。比如：总体进度计划缺乏完整性，也得不到及时修正。进展情况得不到及时汇报，因为职能部门各自制定进度表。计划衔接性差，造成工作衔接性也很差。

产品质量管理尤其薄弱。在源头上，产品需求的定义不准确、不清晰(如客户需求)、不完整(如可靠性需求、可维护性需求);在保证质量的过程控制上，流程本身不规范、不科学，执行不力;在质量控制活动上，缺乏完整的、明确的测试计划和技术评审计划，测试方法和手段落后，测试走过场，技术评审流于形式。

不重视技术积累及平台建设

谈到技术，我们首先想到的是国内企业缺乏核心技术。确实，绝大多数国内企业在技术研发上由于没有长期持续的投入和努力，普遍没有核心技术。但更为突出的问题是对支持产品开发的技术体系缺乏积累和系统性的建设。每一代产品开发都是对前一代产品的否定，没有继承性，缺乏技术积累，直接影响了新一代系统的稳定和推向市场的时间。

不仅在技术上需要积累和共享，元器件、部件、组件也需要通过标准化、通用化来共享。在这方面，国内企业的表现显然也是很差的。国内一家高科技企业在进行器件归一化工作时，发现在公司各种型号的产品中，100欧姆的电阻竟达12种之多。经过分析，最后归并为4种。

缺乏有效的研发人员的考评和激励措施

如何对研发人员进行合理的考核和激励是困扰着企业的难题。一家精细化工企业的人力资源部在推行绩效管理方案是，研发部经理就提出：”做起来是可以，但考得不好，反而起反作用，谁来负责?”由于研发工作的创造性和不确定性，对研发工作和研发人员的评价确实是比较困难。比如说要考产品的市场效益，研发人员会说课题又不是我选的，怎能怪我?再如考计划完成率和错误率，往往越难的项目计划完成率越低、错误也越多，而项目组人员越是辛苦，如果他们的考核却越低，这不是”鞭打快牛”吗?那谁还愿意去做高难度而重要的项目。于是，企业对研发人员的考核在定量和定性之间、在结果和过程之间、在短期和长期之间摇摆，找不到一个行之有效的考核办法。

在矩阵结构下如何对研发人员考评也是一个难点。研发人员面对两个或以上的上级，考核关系如何界定，项目考核和部门考核如何结合，权重如何定，如何对技术部门以外的职能部门参与产品开发的人员进行考核……这些问题让人难以理出头绪。

绩效考核的不科学也带来了报酬激励缺乏依据，带来不公平感，影响研发人员的积极性。如果再加上岗位价值不明确、任职资格划分及评定模糊，那研发人员的薪酬就确实靠拍脑袋了，于是薪酬机制引起更多的不满。在这种情况下，项目奖被一些企业看作是灵丹妙药，可惜项目奖在带来短期的激励的同时，也带来了诸如降低研发人员对企业的凝聚力、影响团队精神、短期行为、不利于人员流动和培养等长期的危害。对于研发人员来说，发展机会、认可、沟通、荣誉等非经济性的激励措施的重要性并不亚于薪酬，但这些也明显被大量企业忽视了。一个企业主抱怨研发人员不愿意加班，但他自己极少与研发人员沟通，研发人员按时下班有班车，晚上加班后回家要自己想办法，更不用说免费的夜宵。试想，在这样的环境下，有哪个研发人员愿意加班?

来自rdeasy

下图是MySQL官方给出了使用Replication的场景：

Replication原理

Mysql 的 Replication 是一个异步的复制过程，从一个MySQL节点（称之为Master）复制到另一个MySQL节点（称之Slave）。在 Master 与 Slave 之间的实现整个复制过程主要由三个线程来完成，其中两个线程（SQL 线程和 I/O 线程）在 Slave 端，另外一个线程（I/O 线程）在 Master 端。

要实现 MySQL 的 Replication ，首先必须打开 Master 端的 Binary Log，因为整个复制过程实际上就是 Slave 从 Master 端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。

看上去MySQL的Replication原理非常简单，总结一下：

• 每个从仅可以设置一个主。
• 主在执行sql之后，记录二进制log文件（bin-log）。
• 从连接主，并从主获取binlog，存于本地relay-log，并从上次记住的位置起执行sql，一旦遇到错误则停止同步。

从这几条Replication原理来看，可以有这些推论：

• 主从间的数据库不是实时同步，就算网络连接正常，也存在瞬间，主从数据不一致。
• 如果主从的网络断开，从会在网络正常后，批量同步。
• 如果对从进行修改数据，那么很可能从在执行主的bin-log时出现错误而停止同步，这个是很危险的操作。所以一般情况下，非常小心的修改从上的数据。
• 一个衍生的配置是双主，互为主从配置，只要双方的修改不冲突，可以工作良好。
• 如果需要多主的话，可以用环形配置，这样任意一个节点的修改都可以同步到所有节点。

主从设置

因为原理比较简单，所以Replication从MySQL 3就支持，并在所有平台下可以工作，多个MySQL节点甚至可以不同平台，不同版本，不同局域网。做Replication配置包括用户和my.ini（linux下为my.cnf）两处设置。

首先在主MySQL节点上，为slave创建一个用户：

GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO ’slave’@'192.168.1.10′ IDENTIFIED BY ’slave’;

实际上，为支持主从动态同步，或者手动切换，一般都是在所有主从节点上创建好这个用户。然后就是MySQL本身的配置了，这需要修改my.cnf或者my.ini文件。在mysqld这一节下面增加：

server-id=1
auto-increment-increment=2
auto-increment-offset=1
log-bin
binlog-do-db=mstest
binlog_format=mixed

master-host=192.168.1.62
master-user=slave
master-password=slave
replicate-do-db=mstest

上面这两段设置，前一段是为主而设置，后一段是为从设置的。也就是说在两个MySQL节点上，各加一段就好。binlog-do-db和replicate-do-db就是设置相应的需要做同步的数据库了，auto-increment-increment和auto-increment-offset是为了支持双主而设置的（参考下一节），在只做主从的时候，也可以不设置。

双主的设置

从原理论来看MySQL也支持双主的设置，即两个MySQL节点互为主备，不过虽然理论上，双主只要数据不冲突就可以工作的很好，但实际情况中还是很容发生数据冲突的，比如在同步完成之前，双方都修改同一条记录。因此在实际中，最好不要让两边同时修改。即逻辑上仍按照主从的方式工作。但双主的设置仍然是有意义的，因为这样做之后，切换主备会变的很简单。因为在出现故障后，如果之前配置了双主，则直接切换主备会很容易。

双主在设置时，只需将上面的一段设置复制一份，分别写入两个MySQL节点的配置文件，但要修改相应的server-id，auto-increment-offset和master-host。auto-increment-offset就是为了让双主同时在一张表中进行添加操作时不会出现id冲突，所以在两个节点上auto-increment-offset设置为不同的值就好。

另：不要忘了，在两个节点上都为对方创建用户。

应用层的负载均衡

本文只介绍了MySQL自身的Repilication配置，在上面的图中也可以看出，有了Replication，还需要应用层（或者中间件）做一个负载均衡，这样才能最大程度发挥MySQL Replication的优势，这些将在以后探讨。

Subversion是广泛使用的版本控制工具。它是CVS的进化，像Google Code，SourceForge等大的网站均提供SVN的支持。

传统配置

SVN的安装并不复杂，如果在Windows下，有专门的Windows安装包可以下载，不过SVN的配置就不那么简单了，所有的配置都要通过SVN的配置文件手工完成，比如用户、密码、权限等。

切换到Http

Svn可以通过Svn自己的服务程序或者Apache来访问，缺省安装的Svn是使用自己的服务程序svnserve来进行访问的。下表对比了两种访问方式的差别：

可以看出使用Apache来访问Svn虽然慢一些，但提供了更好的访问安全性和功能。因此很多团队使用Apache来访问Svn。不过这需要额外安装Apache，并配置Apache和Svn的集成，这需要不小的配置工作量。并且在将来进行用户及权限调整时都需要手工编辑配置文件。

使用VisualSVN

VisualSVN Server则提供了GUI的SVN配置界面，并提供了对Apache集成的支持。安装VisualSVN，则可以直接在VisualSVN的配置界面下进行配置，下图是VisualSvn的基本配置界面。

在左侧可以看到本机上的SVN的仓库和用户，在VisualSVN Server上点右键，在属性中都可以配置仓库的位置、网络、认证、Windows集成、日志，非常方便，如下图：

总之，使用VisualSVN可以大大简化SVN服务器端的配置工作量。