卷首语

实践 健康 创新 家园

【卷首语】

PMBar 项目管理学习型社区 www.pmbar.net，由一群专注于项目管理、研发管理、IT 服

务管理、团队管理等 IT 管理领域的业内专家自发组成。目前，PMBar 社区成员已有全国各

地千余名 IT 领域的项目经理、项目总监、CTO 及 CEO 等，已成为中国最活跃的 IT 项目管理

实践社区！

PMBar 是一个基于实践交流、分享、互动的项目管理社区，旨在为大家提供项目研发管

理交流平台，聚合业内从事和关注项目与研发管理的专家及朋友，进行理论研究、实践分享

和咨询培训指导。

PMBar 的愿景：打造国际国内公认的首屈一指的学习型 IT 项目管实践公益社区，为 IT

人提供全方位的创新性项目管理服务。PMBar 的口号是：实践 健康 创新 家园。

PMBar 社区通过专家讲座、联谊活动、课程体验、专题培训、咨询评估乃至国内外企业

考察等，以及整理 IT 项目管理专业资料、推荐撰写书目、推广网络社区、建立电子会刊、

开展主题展览、进行问卷评测等，向广大社区成员、IT 项目管理人群以及企业提供服务。同

时，帮助社区成员之间、成员与外界之间实现资源对接、商业机会撮合等。

从 2009 年开始 PMBar 社区定期开展线上线下交流，特别是线上"项目管理 MSN 群"每周

二中午 13:00-14:00 进行的项目管理专题分享（在新浪微博 @pmbar 同步）已成为 PMBar

的标志性活动之一，目前已经进行了第 100 期。随着交流的持续，线上即时沟通分享已不能

满足离线社区成员学习、关注 IT 项目管理的从业者交流和 PMBar 社区向外界辐射项目管理

实践知识的需要。

为此，在广大社区志愿者的提议和支持下，PMBar 电子杂志应运而生！

PMBar 电子杂志创刊宗旨，为从事项目管理工作的 IT 人，以及对项目管理感兴趣的 IT

人，营造分享、交流、互动的 IT 文化平台，学习研究和普及项目管理相关体系知识，分享

项目管理成功经验，启迪项目管理中种种困窘的解决之道，推动项目管理的创新。

试刊第一期的主题是“传统与敏捷，我们在什么位置？”。当下，敏捷之风大行其道，

一时间 IT 领域不谈敏捷、不使用敏捷似乎就 Out 了。Scrum、XP、精益、TDD 等为代表的敏

捷思想推广者与传统的 ISO、CMMI、IPD 等开发管理模型和体系实施者之间，产生了大量的

讨论，甚至是火药味十足的争议。为此，PMBar 电子杂志试刊首期，从社区专家自身实践角

度出发，努力尝试给出我们的视角和分析，启迪读者。

PMBar 社区还是个孩童，相信在大家的共同努力下，培养共赢品格（诚信、成熟、知足）、

实现共赢协作，打造一个 IT 项目管理之家！PMBar 期待您的分享并与您一起自我实现！

PMBar 社区创始人 冯国馨

2011 年 11 月

卷首语

实践 健康 创新 家园

联合永道副总兼 CTO、创业合伙人，www.pmbar.net 项目研发管理社区创始人。

长期从事产品研发、项目管理与团队管理工作。2007 年发起定期线上和地面 IT 项目管

理沙龙活动，与用友集团、阿里巴巴集团、盛拓传媒（IT168）、神州数码等企业开展项目管

理沙龙交流。

美国 PMI 协会 PMP 会员、中国系统与软件过程改进协会主任专家会员、中国计算机学

会软件工程师工作委员会委员、北京市商务局 CMMI 认证基金验收组组长、CSDN CTO 俱乐

部项目与研发管理专委会会长、IT168 项目管理超级版主等。

新浪微薄 ID：冯国馨 PMBar

MSN：yulin.gu@hotmail.com

群思荟萃

实践 健康 创新 家园

【群思荟萃】 传统，敏捷，你在什么位置？

“敏捷”，在 IT 开发业内，是近些年的热门词。敏捷是什么？能给我们带来什么？要不

要上？什么时候上？一定要上为什么„„一系列的问题。PMBar 社区在近一年的时间里，先

后正式、非正式地开展过多次探讨，可谓是百家争鸣，精彩纷呈。

本期，我们围绕“传统，敏捷，你在什么位置？”从《暴风影音 5 的敏捷实践》中，发

现其与传统 CMMI 开发模式的差异；从大连海辉 PMO 总监蔡德辉的《敏捷下质量管理的问

题》，到社区在线讲座、部分敏捷专家的微博和博客文章，从框架到细节，从理论到实践，

只希望通过这样的分享，能帮助大家提升对敏捷的认识，揭开敏捷的神秘面纱。量体裁衣，

实践才是硬道理。

特别鸣谢：敏捷专家陈勇，在采编和审稿过程中的鼎力协助。

暴风影音 5 敏捷项目管理实践

暴风影音 CTO 杨立东 北京 100191

2011 年 10 月 26 日，网络和众多传媒上炒得沸沸扬扬的暴风影音 5“左眼”技术终于

落地了，现场嘉宾和记者无不为这项技术所震撼！这一成功的背后是一群疯狂的程序员付出

的 4 个月封闭和 6 个月长期加班，也是一次敏捷项目管理实施的成功案例。

一年前，CTO 俱乐部的“软件开发模式思考：传统与敏捷 我们在什么位置？”的主题活

动中，我分享了项目管理和 CMMI 的话题，那时候我刚加入暴风，虽然不是创业团队，但成

为了暴风历史上第一个 CTO，按照以往的管理经验，先审查研发工作中最基本的配置管理、

缺陷管理和一些基本流程。期间，我也在寻找实施敏捷项目管理的契机。终于，在暴风影音

3 的官网项目上，开始了尝试敏捷项目管理的步伐。

根据软件开发项目的特点，结合新开发管理模式的实践，我抽取六个敏捷实施中的片段，

与大家分享。

一、 启动阶段定规矩

刚开始，面对很多新鲜且陌生的词汇，什么 Sprint，什么 Product Owner，研发团队还

是不太容易接受的。

另一头痛问题是迟到，迟到是研发团队一个顽疾，每天上午 10 点，15 分钟晨会，经常

是很多事情不知道进展，需要敏捷教练私下里一个个地核对，敏捷实施可谓困难重重。在忍

耐数天之后，我在晨会上做了一个规定：如果谁再迟到，罚款 50。这笔钱作为项目活动经

费由敏捷教练来支配。这招果然好使，让晨会制度慢慢有效起来。尽管后面还有一些同事迟

到，但大家开玩笑地说“以后谁再迟到就办个包月吧，省的每天都交罚款了”。

在每天看燃尽图的过程中，一个里程碑很快就结束了，可大家并没有什么特别的感觉。

除了每天晨会，看燃尽图，觉得和以前没什么两样，只是每个人慢慢开始了解其他人都在做

什么了。总结起来，这次试水并不算完全成功，因为，除了燃尽图、晨会、Sprint 回顾会议，

与其他种种的项目开发模式并没什么实质性变化。然而，有三方面的收获，是大家由心底感

受到的：

群思荟萃

实践 健康 创新 家园

建立了共同的沟通渠道；

敏捷项目管理的词汇不再陌生，甚至变得亲切；

项目的进度透明了，彼此加深了解，也方便沟通。

如果说敏捷，就是解决以上三方面的问题，那就未免太低估了“敏捷”这个词背后的伟

大意义。我们还没有工程实践，没有敏捷估算，没有相互协助，没有准确地解读燃尽图，离

敏捷到底有多远？

二、 旧代码重构——痛苦的决定

年底业务规划会上，一次由程序员主导的呼声响起了——

老黄，暴风影音研发团队负责人，用他并不擅长的演讲，给我们讲解为什么暴风影音需

要重构，当前的产品存在哪些不好解决的缺陷。听到了很多技术细节之后，我越来越感到心

惊，原来老的产品有那么多设计不合理的地方。

但如果重构，我思考的问题有两个：

这个项目的规模有多大？

重构的周期有多长？

跨全公司范围的所有部门进行重构，又不影响正常业务，这么复杂的一个项目能成功吗？

敢在这个最重要的项目上实施敏捷项目管理吗？讨论了很多次，重构在我脑子里也进行了不

知道多少次，最后的决定是：重构，实施敏捷项目管理！

定义项目的目标和 Sprint 划分是立项准备工作的一部分内容，最早的目标是 6 个月发正

式版，由于跨春节，初步决定按 5 个 Sprint 进行管理。

Sprint 1 建立播放器原型 2011-01-04 至 2011-01-25

Sprint 2 提交稳定的播放器 2011-02-14 至 2011-03-31

Sprint 3 提交可发布的播放器 2011-04-04 至 2011-04-30

Sprint 4 提交观察员公测 2011-05-01 至 2011-05-31

Sprint 5 提交 Beta 版 2011-06-01 至 2011-06-30

三、 架构评审

架构评审是我们引入的第一个工程实践，评审资料的准备，资料预读，提前抛出问题，

问题讨论，架构修改。在以前，还从来没有过这么复杂且流程严格的评审。每次评审我都让

各个研发骨干不留任何情面地提问题，老黄一次又一次地争论和修改。但大家都明白只有合

理的软件架构才能让这个软件走得更远！

架构评审中，属性驱动设计（ADD – Attribute Driven Design）是我们采用的设计思想之

一，将模块分解建立在那些必须满足的质量属性上。这个思想让每个成员都更重视质量属性。

经历多次架构评审之后，终于开始做任务拆分了。

四、 任务分拆与估算

刚开始做任务分拆和估算的时候，挺有故事的。Sprint1 的任务拆分感觉不够细，所以

群思荟萃

实践 健康 创新 家园

打回重新分解。什么叫“细”，我定下了一个标准就是：估算工作量需要在 24 人时内完成。

起初，研发负责人老黄给每个人估算了工作量。当我参加计划会议的时候，估算结果早

已出来了，这让我很惊奇。我让敏捷教练把估算好的结果打印了一份，然后去掉老黄的估算

结果让他对着投影再估算一遍，然后让大家验证。结果有一半都和之前的结果不一样，在大

家的哄堂大笑中重新开始了估算。没有专业的敏捷扑克，我们就靠喊，在大家的呐喊声和老

黄的打压声中，每个人的估算结果终于汇总出来了。

五、 需求，一个老话题

历来，需求都是软件项目管理的难题之一。这次为了管理好需求，我们选了公司最好的

产品经理干哥定需求模板。当研发人员都喜欢看，带有标准的建模工具画出的逻辑图出现在

我们面前的时候，大家都觉得这次需求很靠谱。

借鉴以往和产品人员打交道的经历过程中，反复是常有的现象。所以需求评审和基线化

是这个项目实施中最重要的实践活动之一。

六、 代码与发布

一个个的里程碑过去了，产品和研发的配合也越来越默契。

随着代码越来越多，代码集成成了很大的问题，每天依靠一个负责任的测试人员来管理

版本和编译打包有点落后了，为此引入一套自动打包和编译的工具很有必要。经过筛选，我

们引用了 Hudson 和 SVN 配合做自动化。在封闭开发期间，每天定时下午 6 点进行打包编

译，测试回归前一天的 Bug，开发工作按正常的进展进行。开发和测试之间的配合也越来越

默契了。

七、 总结会上

6 月底版本的测试结果并没有达到预定目标，最重要的指标——启动速度，还是没有达

标。经过反复的商议，我们决定延期项目，一定要拿出性能卓越的产品，所以才有了启动速

度最快的播放软件和画质提升显著的“左眼“技术的问世。

在 8 月份 Beta 版本发布后的 Sprint 总结会上，大家总结这次重构项目的得失，其中成

功经验最终被合并成了三条：

1、敏捷项目管理的实施让大家时刻关注目标；

2、测试把控质量标准严格；

3、所有人员以主人翁的姿态参与，大家都有了赢的欲望。

群思荟萃

实践 健康 创新 家园

敏捷质量管理

P.S：要效率，也要质量，当敏捷试行，质量监控如何同步跟进？大连海辉软件(国际)

集团公司，质量与安全总监蔡德辉，10 月份做了一次线上的 PMBar 讲座，主题是《敏捷下

质量管理的问题》，受到社区的广泛好评，本期蔡德辉先生根据分享的内容，从敏捷模式质

量管理的根本原则到具体实践，由理论体系支撑结合实践，让大家进一步提升认识。

（一）敏捷质量管理的原则

核心观点：

灵活运用敏捷质量管理的最佳实践，把这些最佳实践应用到敏捷过程中，能够有效地提

高效率，在迭代过程中不断改进质量。这些实践强调不断第反馈和证实，也有利于团队之间、

团队与客户和用户之间的不断交互，这些方法简单而实用，是敏捷开发成功的保证。

蔡德辉

海辉软件(国际)集团公司 质量与安全管理部 大连 116023

【摘要】本文讨论了敏捷质量管理的原则，从客户参与、过程驱动、预防、基于事实的

改进四个方面阐述了这些原则以及其再敏捷开发中的应用。并提出了一个敏捷和软件产品开

发结合的过程模型，供应用者参考。

【关键词】敏捷、质量管理原则、过程模型、敏捷度量

从 2001 年敏捷宣言发布至今已有 10 年时间，在这 10 年里，通过不断的鼓吹、打磨、

淬火，基于敏捷的软件开发已经成为主流的软件开发方法。以客户价值为导向，鼓励客户参

与、强调团队互动和可工作产品的敏捷得到了客户的青睐，并取得了很多成功的案例，这鼓

舞了更多的企业加入到敏捷的队伍中来，采用敏捷的方法实施软件项目。

敏捷是不是就不要过程，不要质量，不要数据，不要改进了呢？不是，敏捷强调的是快

速响应，强调的是价值驱动，现在敏捷的方法论无论 Scrum、XP、DSDM，更多是一个管理

框架，他们本身需要与软件工程、质量管理结合起来才能使用。敏捷从一开始就非常重视质

量，通过客户的深入参与、团队互动，迅速构建可工作的产品，得到了业界，特别是客户的

认可。这种快速反应，有利于更快地厘清需求，开发出可以使用的产品，得到客户和用户的

反馈，从而不断改进，这是开发产品的优秀的方法，但如果我们不适当地加以控制，就很可

能落入到需求不断变化、产品基础不稳、团队混乱的地步。为了防止出现这种情况，敏捷项

目应该遵循一些基本的质量管理原则。本文在实践的基础上，简单阐述以客户参与、过程驱

动、预防和基于事实改进这样的四大质量原则，希望能对大家有所帮助。

一、 客户参与

客户是谁？客户的目的是什么？我们为客户创造什么价值？我们应该如何与客户保持

协作？这是每个项目一开始就需要定义、分析、理解并在项目整个过程所贯彻实施和验证的。

敏捷四大宣言，将客户协作作为其中之一，可见其对客户的重视。客户在项目一开始得

到定义，并全程参与整个项目。团队在一开始应该理解客户的业务目标，理解项目为客户带

群思荟萃

实践 健康 创新 家园

来的业务价值，理解客户的关注点，在整个项目过程中贯彻始终；客户在项目过程中，需要

明确项目的范围；决定需求的优先级；对实现后的成果进行确认与验收；及时反馈结果并进

行调整。这些要素突破了以往软件开发，客户草草提供需求，中期不管，后期才来验收导致

的沟通不畅，理解偏差等导致的问题。

二、 过程驱动

过程方法是现代质量管理的基石。只有通过系统的识别、定义、实施、改进过程，方能

够不断地提高效率、质量，达到最优。敏捷开发一开始提出四大宣言，其中第一条就提出个

体和互动，高于流程和工具。仿佛将过程打入了冷宫，这是对过程的误解。个体和互动本身

和流程并不矛盾。敏捷的大师们在经历了繁重的过程后，基于自己的工作经验，反思软件开

发的创新要求，提出个体和互动高于流程和工具这是可以理解的。他们认为对于创建软件产

品来说，创造、创新比过程更重要，而创造、创新更强调个体和互动。尽管如此，我们审视

软件产品开发的全过程，初级创意以及架构和高端的设计创造和创新占据主流，但当软件一

旦进入到细节设计、开发、测试等工作中后，尽管创造和创新还存在，但更多类似制造的工

作，而对于制造的工作，遵循过程是保证质量，提高效率的关键。

图 2-1 敏捷过程框架

在敏捷项目中，笨重的、纷繁复杂的过程，将被适应于敏捷的、更灵活的过程所代替。

这些过程一旦定义也需要得到遵守，并收集过程数据，并进行改进。例如定义一个 Story 的

实现过程，从需求理解、设计、实现、测试、Show、验收的过程。系统的定义过程，也有

利于团队进行沟通，确定团队所处的位置和状态，有利于培训与提高。

图 2-1 是基于敏捷的集成软件产品开发的基本过程模型。该过程模型结合了产品开发的

要求，包括了管理与技术的评审点；提出了一些重要的整体过程，包括需求分析、架构、系

统设计与框架、以及后续的回归验证、系统集成测试、系统验收测试等内容，这部分内容代

表了对于产品来说，高端的设计与思考是成功的关键，这些部分也可以组织为阶段或者迭代。

这对敏捷中迭代的划分提出了更符合产品开发的思考。对于实施阶段，我们可能有多次迭代，

群思荟萃

实践 健康 创新 家园

这些迭代的过程，也是清晰的，是团队应该遵守的。

三、 预防

传统软件开发方法过于重视测试的作用了，围绕测试甚至建立了 X 模型，将测试提到了

与开发过程的同等地位上，主要原因为:

1、由于软件开发本身的巨大不确定性导致的；

2、软件开发行业缺少好的缺陷预防的方法；

3、由于软件行业的从业人员本身的认识与素质造成的。

这三个原因，导致软件行业的质量成本超过 30%，有的甚至达到了 50%，这在传统行业

看来是不可思议的。

目前软件行业针对在三点也在展开研究：

针对第一点，目前开展的模式研究、成熟的基础框架、组件、SOA 等都是这方面的努力；

针对第二点，敏捷所推崇的客户的长期参与、测试驱动开发、持续集成、每日构建等最

佳实践，就是缺陷预防的方法；

对于第三点，需要教育、培训、企业和从业者共同努力。

预防重于纠错。从敏捷一诞生的时候，就贯彻了这个思想。作为从事敏捷工作的从业者，

要认识到其中的重要性，贯彻执行有关最佳实践。

敏捷软件开发围绕预防创造性的使用了诸如各种反讲、评审、原型、Show、客户的深

入参与、持续构建与集成、迭代回顾、可工作的软件等最佳实践，并综合运用各种工具来预

防、提高开发的质量，这些实践和工具被巧妙地安排在敏捷的全过程，较之传统软件开发通

过繁重的文档和评审更能够保证产品的质量。

四、 基于事实的改进

一个方法，一个过程必须要有能力不断学习，不断改进，才能够进化到最佳状态，并适

应环境的变化。改进也是现代质量管理最重要的要求。围绕改进已经形成了系统的定义过程、

实施度量分析、不断的改进并验证结果的完整方法论。我们只有搞清楚了生产率、成本、缺

陷率等指标，才能够有效的度量出现在的状态，未来的改进方向和改进的效果。

软件行业从诞生开始就受到一个困扰，那就是数据不足。没有数据，何谈改进。如何使

软件行业的从业者能够有效的收集与提供成本、规模、工时、工期、缺陷等数据成为目前软

件行业的难点。这也是一个行业成熟的标志。不管是敏捷还是其他方法论，都必须支持这一

点，否则没有改进，就只有消亡。

敏捷软件开发每次迭代的周期比较短，我们可以在每次迭代中收集质量、成本、进度等

数据，并在迭代结束时的回顾会议上进行分析与讨论，使项目组能够清楚的把握自身的能力、

产品的质量，并分析需要改进的过程和方法。

关于敏捷如何度量，最近在敏捷业界引起了广泛的讨论，Esther Derby 在“敏捷的度量”

文章中提议度量下列指标：

修理缺陷工作量和开发新特性工作量的比率

群思荟萃

实践 健康 创新 家园

周期时间

遗漏到产品中的缺陷

Isaac Montgomery 则在“衡量敏捷投资的影响”中建议采用的指标下面的指标：

生产率

质量

反应速度

客户满意度

员工满意度

可预测性

通过实践，我们建议的对项目执行结果的度量指标如下：

客户满意度

交付质量

按时交付率

按时响应率

团队满意度

成本（或者毛利率）

生产率

不管我们采用哪些指标，我们需要非常关心数据的采集方法和度量与分析的时刻。考虑

到敏捷的特性，建议是在每个迭代过程中进行采集与度量，在迭代回顾会议上进行分析，并

制定策略进行改进。

除结果指标以外，我们有的时候会需要过程的指标来保证我们的结果能够达到，常见的

过程指标包括代码的抽检率、设计评审缺陷率或者测试覆盖度、代码的圈复杂度等，这些过

程指标如果要采用，一定要保证团队能够充分认识到他们的作用，在工作中不需要做太特殊

的工作就可以做到。

在进行数据收集、度量分析与改进的时候，要注意不要认为引入过多的指标而成为累赘，

是否采用某个指标，取决于项目的情况，这需要在计划阶段进行决策。

【总结】

客户参与使团队总是关注在价值最高的事情上，并不断推出可以使用的软件而不断获得

反馈；过程驱动使团队能够协调一致、进退有据，更利于管理和提升效率；预防是获得高质

量产品的关键；基于事实的改进为这些提供依据，这四项质量管理的原则与敏捷思想的有机

结合，可以使敏捷开发更有效率、质量更高、过程更可控。

如何有效的应用这些质量管理原则，敬请关注本系列之二：敏捷质量管理最佳实践。

【参考文献】

[1] Ken Schwaber 著 李国彪译 Scrum 敏捷项目管理 北京 清华大学出版社 2007.

群思荟萃

实践 健康 创新 家园

[2] ISO ISO9001-2008 质量管理体系 要求 2008.

[3]Steve McConnell 著 席相林 译 快速软件开发 北京 清华大学出版社 2008.

[4]Marc McDonald Robert Musson Ross Smith 著 李滋堤 译 完美软件：缺陷预防最佳实

践 清华大学出版社 2010.

[5] www.agilemanifesto.org ]敏捷软件开发宣言 http://www.agilemanifesto.org/iso/zhchs/.

[6]詹姆斯.R.埃文斯 威廉.M.林赛 著 焦叔斌主译 质量管理与质量控制 北京 中文人民

大学出版社 2010

[7] Esther Derby 著 Metrics for Agile www.estherderby.com/2011/10/metrics-for-agile.html

[8]Isaac Montgomery 著

www.rallydev.com/agileblog/2011/04/measuring-the-impact-of-your-agile-investments/

群思荟萃

实践 健康 创新 家园

（二）敏捷质量管理最佳实践

蔡德辉

海辉软件(国际)集团公司 质量与安全管理部 大连 116023

【摘要】本文讨论了敏捷质量管理的最佳实践，包括需求控制、架构设计与反讲，团队

设计与串讲、模式应用、Code Review、Show、成果限样确认、工具应用等 8 个最佳实践。

这些最佳实践被应用在迭代过程中，为提高产品质量、提高效率起到了关键作用。

【关键词】敏捷、质量管理、最佳实践

团队在敏捷质量的四项原则基础上，需要遵守质量计划、质量控制、质量保证与质量改

进的质量管理过程，将质量管理过程的要求，融入敏捷的要素，形成了自己独有的最佳实践。

对这些实践的灵活运用，可以开发出质量高而稳定的软件产品。

一、 需求控制

Standish Group 每两年一次发布的 Chaos 报告中，软件项目的成功率都是很低的，1994

年为 16%，2008 年为 32%，而给出的项目失败的原因中有超过 50%与需求有关，可见做好

需求控制对软件项目来说至关重要。

敏捷开发推崇客户的广泛参与、反馈、可以工作的软件、通过产品 Backlog 和迭代 Backlog

的方式来进行需求管理，这很好的响应了 Standish Group 提出的十大成功要素中用户参与、

清晰的业务目标的两个目标。

在敏捷中实施需求管理，需要遵循记录、分

析、复述、原型、估算、实施、核实这样的 7 个

步骤。复述、原型就是非常重要的质量保证方法。

无论在什么样的工作环境下，返工永远是成

本最高的，而复述和原型可以防止需求理解错误

导致的返工。复述就是客户讲完以后，项目组按

照理解重讲一遍，客户再确认，双方不断的讨论

最后达成一致。

原型是在这之后进一步的确认，有的需求，

客户过一段时间可能会有一些新的看法，在原型

阶段就可以及时反馈，而原型才是最终软件交付

后的样子，也可以让客户尽早看到工作的样子，从而再次讨论。

有的敏捷方法如 Scrum 中，认为在一次迭代中，需求变更是不允许的。这个提法有点

绝对，应该从两个方面来看，一方面就是从大的方面来说，在确定好迭代的 Backlog 以后，

这个范围应该是被严格控制的，如果要发生变更，则要考虑取消迭代，因为迭代本身周期很

短，如果折腾一次不值得了，不如干脆重来；另外一方面，某一个特性的内部细节发生变化，

这应该是被允许的。因为客户毕竟不是软件专家，他所想象的系统的行为，可能和我们的理

解不一致，因此这个变化是不可避免的。问题是项目组要能够判断这个变化对迭代的影响，

最好控制在 10%以内。

群思荟萃

实践 健康 创新 家园

二、 架构设计与反讲

架构是一个软件的基石，尽管架构的发展也会随着项目的变化而变化，但一开始尽可能

设计与实现一个完善的架构，是任何一个软件项目要追求的。没有良好架构的软件，就是没

有打好基础的摩天大楼。只是软件和摩天大楼的不同处是，软件的架构可以在一定的范围内

演化。尽管如此，也不意味着不要求设计完善的架构。随着模式的发展，架构设计也越来越

有迹可循，这会提高软件项目的成功率。

敏捷项目通过迭代来组织项目的进程，迭代本身可以划分为需求迭代、架构迭代、整体

设计迭代、N 次功能迭代、特殊迭代、测试和验证迭代等很多类别。架构迭代应该是其中非

常重要的迭代。

尽管架构本身对设计师的要求很高，但大部分项目组成员只需要理解和应用架构。问题

是，他们真的理解架构了吗？为此我们有必要设计一种质量保证方法来保证团队真的理解了

架构，这个方法就是架构反讲。架构设计师或者主设计师向团队讲述与演示了架构以后，每

个团队成员要根据自己的理解重新讲述一遍，然后大家一起来进行 Review，找出正确与错

误的地方，不断调整，直至完全正确。团队成员在这个过程中能够迅速的认识未来系统将如

何发展，系统的质量能够得到保证，成员的能力也会迅速提升。

三、 团队设计与串讲

尽管我们期望团队的成员都是训练有素的，每个人都已经能够完成自己的工作。事实上

我们组建的团队一开始能力差异很大，如何才能保证交付的质量？敏捷希望每个团队成员都

了解系统的结构，都能够进行设计、开发、验证。这就要求我们必须有一种方式，能够弥补

由于个人的能力不足导致的问题。

这个方法就是团队设计和设计串讲。我们将设计过程调整为：首先，团队一起讨论本轮

迭代的整体设计，系统将如何演变来满足本轮需求的需要；然后对每个 Story 进行讨论，形

成设计方案；然后负责 Story 的人在会后将设计方案进行完善；最后再组织团队会议，由 Story

负责人进行设计讲解。这个团队设计与设计串讲过程能够迅速提升团队的设计能力，也能够

有效地保证产品的质量。

四、 模式应用

业内提到模式，通常让人想起设计模式，其实设计模式只是软件众多模式的一种。

模式是对常见问题解决方案的总结，目前模式的范畴很广，覆盖了软件开发的各个部分，

业务、需求、架构、设计、代码、测试、用户习惯等都总结了出了相应的模式。模式中提出

的解决方案，都是经过了多次验证，只要使用得当，就可以做到缺陷少，效率高。

模式的采用，也能够快速的提高效率，改善沟通。敏捷开发的倡导者都是现代软件开发

思想的鼓动者，他们中很多人都是模式的专家，致力于推动软件社区来接受、使用、总结新

的模式。作为敏捷的应用者，由于追求较少的文档，敏捷的过程，模式的应用是非常关键的。

较少的文档，不代表较少的设计，使用模式是有效降低设计难度，减少文档的关键，也是提

高软件质量关键。

群思荟萃

实践 健康 创新 家园

模式可以重复使用和改进，模式本身又是通过了验证的解决方案，因此模式的应用也是

缺陷预防的重点。

五、 Code Review

Code Review 可以划分为自检、互检、小组评审三种形式。

开发人员应该养成编码完成后进行 Review 的习惯，一方面检查各种风格、格式等简单

的问题；另外一方面从设计出发重新检视代码，保证达成设计要求；另外需要在 Review 中

不断的询问自己更简单、更有效的方法，不断优化代码。敏捷强调代码要简单、易读、易懂，

要做到这三点不容易，一般在第一遍编写代码的时候，考虑的是如何实现，只有在 Review

代码时才会考虑其他问题，因此多次自检对程序员来说是很重要的。

互检可以发现自检发现不了的问题，有的时候程序员会对自己放松要求，通过互检就能

很好的检验合规性、符合设计、优化、简单、易读、易懂的要求。如果互检的时候，对方都

看不懂，那么代码肯定要进行修改。互检的时候，也能相互学习，快速提高。

小组评审在团队成员能力不足的时候用得比较多，小组评审需要评审成员提前阅读代码，

标记疑问，评审的时候提出来，这将消耗一些时间，但是大家可以从小组评审中迅速提高自

己的能力。

做 Code review 一般较难记录所有的缺陷，最好准备好一个常见缺陷清单，原本是在开

发前使用的，用来做缺陷预防，但现在可以用来做快速的缺陷记录，遇到问题，只要画正字

或者打钩就可以，这有利于后期进行分析和改进，也可以改进缺陷预防表。预防缺陷产生的

成本总是比较低的，缺陷一旦产生，记录、重现、定位、修复、验证、展开的过程非常的耗

费时间，因此 Code review 较后期的测试能够更节省时间。

六、 Show

向客户展示系统就是迭代 Show，向团队展示某个 Story 就是 Story Show。Show 本身是

群思荟萃

实践 健康 创新 家园

很简单的，但 Show 代表了一种成果的展示，代表了一个阶段的结束，代表了得到验证和获

得认可。Story Show 和迭代 Show，是最重要的过程之一。客户和团队从 Show 中获得直观的

认识，对项目的进展进行评价。Show 对于获得最后的反馈来说，是很重要的。团队、客户

和用户都能够在这个机会再次做出确认和改进，使最后的系统更能够满足客户和用户的需求。

Show 是实现以后，交付之前的一次改进机会，这个机会代表软件已经得到实现，客户和用

户最终已经知道软件的样子和行为模式，能够更好的理解软件，这是开发一个优秀软件所必

不可少的步骤。这个循序渐进的步骤，也有利于客户消化、理解和接受软件，这是传统软件

开发所不具有的方法，有利于成功交付软件产品。

七、 成果限样确认

在项目开发过程中，不可避免对于某些内容还没有成熟的标准和格式可以参考，我们应

该怎么办？很多团队都是直接做完，然后再确认，不行再改。这是一种不好的习惯，会导致

大量的浪费。这种情况下我们应该先制定标准和格式，与客户进行确认后，再根据标准和格

式完成几个部分，再次与客户进行确认，就是限样确认。

限样确认是比较适合软件行业使用的，当我们对 UI、报表定不下来的时候，当我们对

设计文档写成什么样子定不下来的时候，就应该使用限样确认的方法来逐步确定。使用限样

确认可以有效降低由于这种不确定所导致的浪费。

八、 工具应用

软件开发本身是一个复杂的过程，要想敏捷起来必须借助工具，尽管敏捷宣言一开始强

调个体与互动重于过程与工具，但这不代表敏捷社区轻视工具。相反经过 10 年的发展，敏

捷社区采用了大量的工具，来自动化开发中的很多工作。这些工具从代码检查到持续集成到

自动化测试，不一而足，在敏捷开发中立下了汗马功劳。

对于代码的静态与动态检查、持续集成、配置管理、每日构建、单元测试、自动化测试、

自动化文档工具，目前在各种语言和 IDE 环境下都已经存在，并运用良好，得到像 Microsoft、

IBM 等开发工具厂商的支持。应用工具可以代替人力进行规范检查、配置、集成和测试，能

够更快、更早获得软件运行的结果，并及时进行调整，从而不断的提高质量。无法想象没有

工具的敏捷过程，还能否敏捷起来。

【参考文献】

[1] Ken Schwaber 著 李国彪译 Scrum 敏捷项目管理 北京 清华大学出版社 2007.

[2] ISO ISO9001-2008 质量管理体系 要求 2008.

[3]Steve McConnell 著 席相林 译 快速软件开发 北京 清华大学出版社 2008.

[4]Marc McDonald Robert Musson Ross Smith 著 李滋堤 译 完美软件：缺陷预防最佳实

践 清华大学出版社 2010.

[5] www.agilemanifesto.org ]敏捷软件开发宣言 http://www.agilemanifesto.org/iso/zhchs/.

群思荟萃

实践 健康 创新 家园

[6]丹尼尔.弗里德曼 杰拉尔德.温伯格著 唐云深 胡庆培译 走查、审查与技术复审手册

—对程序、项目与产品进行评估 第三版 北京 清华大学出版社 2003

【编后语】作为敏捷质量管理在线讲座的总结，蔡德辉先生先后绘制了两份质量框架图

示，还在继续完善中，在编辑的鼓励之下，蔡先生同意先发表出来引发大家的思考和碰撞。

以可工作软件为核心的敏捷质量管理体系

以团队为核心的敏捷质量管理体系

群思荟萃

实践 健康 创新 家园

微观点

围绕“传统，敏捷，你在什么位置？”，除了我们从因敏捷与 CMMI 的差异，给开发团

队带来的冲击与适应，以及随之而生的质量管理，还有很多细节需要展开与深入。本期分享

有关用户故事与用例、测试等微话题，旨在抛砖引玉。我们欢迎大家将更多的实践应用经验

拿来，一起分享，促进我们共同成长。

一、 传统开发遇到了什么困惑？

（出处 PMBar 主群讨论）

【大卫张 2011-09-06】

瀑布有啥缺点？这是 10 年前的提法。敏捷在 10 年前刚刚出道，得找个对手打响自己的

名号。找谁呢？瀑布如日中天，不找它找谁？瀑布有啥缺点呢？一次交付，成本不可控，风

险不可控。所以敏捷前期用这个来宣传，咨询师用这个来找市场，还真的灵了。这里并不那

么严谨，这是一种宣传，是市场的力量在推动。

大卫张 33-PM-成都说:

瀑布有啥缺点呢？一次交付，成本不可控，风险不可控。所以敏捷前期用这个来宣传，

咨询师用这个来找市场。还真的灵了

zhang_产品部经理_bj_微博：zhang_pmbar 说:

瀑布法不能控制成本吗？

陈加兴-研发经理-成都说:

但我自己的经历还没遇到过“瀑布的缺点”

lastwinner-pm-bj 说:

瀑布方式有里程碑可以控制，敏捷的那说法是忽略客官（编辑注：应为“客观”）事实

的

陈加兴-研发经理-成都说:

大部分项目失败的原因都不在用了“错误的”开发方法或是没有用“开发方法”

兔子瞧-PMO 顾问-北京说:

瀑布的缺点是造成人们对变更的厌恶

二、 用户故事与用例

｛出处： http://weibo.com/2143919827/xs4ygeIBy }

【徐锋 2011-10-10】

#用例和用户故事#用例本身的局限性在于它仅对“功能需求（或称行为需求）”更合用，

群思荟萃

实践 健康 创新 家园

而用户故事倒可以摆脱这样的困难。用户故事的局限性在于对于较大规模系统时，使用者很

难有效地保障其完整性。

【徐毅 2011-10-10】

我倒觉得两者相得益彰。用用户故事着重挖掘实际用户的需求，可以看做更偏向于“用

户、市场要求”，而用例侧重描述用户角色与系统之间的交互，以及系统对此的响应，更侧

重在描述系统的功能。恰好用到两者的优势，形成互补。

三、 关于测试

｛出处：http://weibo.com/1652927771/xsKjBaChk }

【朱少民 2011-10-15】

我刚才看到一个大会演讲稿，谈到敏捷测试六大指导原则：1.仅靠测试人员不可能获得

高质量的软件，质量是整个研发团队的责任；2. 场景是不可穷举的，测试活动必须是风险驱

动的，关注于高风险的场景；3.分层自动化测试是唯一出路;4.在正确的位置进行恰当的测试

是自动化的关键；5.引入好的测试框架和测试驱动工具非常重要；6.开发测试应在同一迭代

之内完成。 我几乎没感觉这些有什么特别之处，而只适合敏捷测试？ 对传统软件测试依旧

适合。也许传统测试就根本没做好，把过去早已存在的测试原则都扣在敏捷测试上

出处：

http://52show.sinaapp.com/index.php?m=show&id=33688847515145

58 }

【吴穹 2011-10-15】

目标和手段是相对的 更快地交付高质量的产品也可以认为是手段 而回报股东会服务社

会是目标 如此形成一个目标 手段 链条 是目标还是手段是相对的//@朱少民老师:回复@吴

穹 adam: 持续测试、持续质量反馈还是手段、方法，不是目标，目标还是更快地交付高质量

的产品。

四、 敏捷部署

｛出处：

http://52show.sinaapp.com/index.php?m=show&id=33578084

16676313 }

【王晓明 2011-09-15】

对于一个团队你是不是敏捷了我不在乎，我在乎你有木有用科学的方法解决项目中的问

题了？团队成员能力提高了木有？用户对我们产品的反馈变好了木有？团队效率提高了木

群思荟萃

实践 健康 创新 家园

有？产品质量提高了木有？如果你采用了敏捷方法，你的团队可以快速迭代木有？你的项目

始终做最有价值的事情了木有？

｛出处：http://weibo.com/1495430110/xshERujt0 }

【张克强 2011-10-11】

#敏捷改进#的状态应当是很微妙的平衡，既不是在重重已定义过程范围内照着做，也不

是没有已定义过程随意的做，而是位于边界处，以开放的心态，以已经存在的现状和已定义

过程为基础，向着组织商业目标，探索新的更好的做法，可以参考业内公开的有效方法实践。

五、 {产品管理

｛出处：http://weibo.com/1907298003/xpwWXkzwp }

【陈勇 2011-10-06】

无论有多少种方法对优先级进行排序，作为产品而言，都永远应该把最体现差异化价值

观的功能置于万事之前。作为项目开发而言，则应该把造价估算和跟踪置于万事之前。

敏捷方法实践话题非常多，即便是专家之语，也不见得就是完全正确的，如果您对上述

话题感兴趣（不限于上述话题），可以在主群、水群、微博上继续深度交流，PMBar 也将继

续关注敏捷，敬请广大读者积极投稿，投稿地址是 editor@pmbar.net，写出您的心得，分享

您的实践，期待您的亮剑……

【本期《群思荟萃》责任编辑张权，感谢 陈勇 对本栏目的采编、审校】

项目案例

实践 健康 创新 家园

【项目案例】

【编按】：需求，变了又变，还不给加钱；代码，改了再改，还问题越来越多；沟通，

电话、邮件，仍无穷无止„„作为项目经理，每天都会遇到一些棘手而又不得不面对的问题，

你需要急中生智、审时度势、果断决策，还需要灵活应变，善于周旋，一些问题普遍存在，

又都各有不同。如何披荆斩棘，拾阶而上？本栏目摘录一线现场的真实场景还原，典型问题

的不同处理，资深经理们的众说纷坛。关于进度、沟通、决策、补救；关于为人处事的洞察。

希望能带给您多少的启发。

经验沉淀、汇聚便是财富，难题困扰这里有专家出谋划策，欢迎您的分享、参与。

案例一：如何进行集团内部招投标项目的开发实施？

案例提供 / 谷雨霖

行业：IT

项目阶段：执行阶段

项目背景：

一个内部招投标的项目，招标时加上了日常管理这个部分。日常管理包括 ABCDEFGH...

十几个子功能模块,标价只占 7 万。每个子功能的业务由客户单位不同的人员分别负责，只

能分别调研，每个人都对系统提出了不同的要求，恨不得实现 100%的完全信息化。由于内

部单位，我司不好拒绝，后期还希望他们帮我们推广说好话。我方经过努力开发，基本完成

任务，成本早就远远超过 7 万。结果十几个子功能模块只有 5%的功能得到使用，其余全部

闲置,开发人员积极性受打击。验收推进缓慢(目前已经验收)，还时不时冒出新的需求要求继

续开发，满意度也不高。因为后期希望他们帮我们推广说好话，项目经理没法不答应。客户

领导甚至暗语我们送给他们一些设备，老板也答应了。目前又到了签订维保合同的时候，客

户继续以新的需求为条件才答应。事实上，系统一个也没有推广出去。

分析要点：

1.请指出项目中出现的问题及原因?

2.正确的做法应该是什么?

3.目前应该怎么办?

问诊出谋，众说纷纭

马兆林-cio-京 说:

把这个“日常管理”模块单独拿出来，其它部分先验收；否则会影响整个项目的进度，

甲方也会不满意的。如果合同已打包，则加签补充协议。要做甲方的工作，不能因为局部影

响全面，也会影响甲方的进度，站在甲方的立场。

1）首先甲方对 IT 的实现认识有问题，不能解决全部问题；

2）甲方对自己要什么不清楚，变更快；

3）乙方无限制的答应开发，没有自己的判断和项目管理。

项目案例

实践 健康 创新 家园

结论：

1）项目下马，乙方不要在投入录入，无底洞；

2）提升甲方的 IT 认知，我管它叫甲方的 T 商，最好甲方有个项目管理的明白人沟通，

当然这个人还要有强势和决策权重，这方面条件具备了，再谈需求细节。锁定需求，双方确

认开发任务和工作量；

3）对于这类客户，需要乙方有优秀的项目经理。

Hawk-PM-苏州 说:

PM 发正式通知，需求收集截止时间是什么时候，过了这个时间，不再接受新需求，否

则案子只能一直做下去了

Ted-项目经理-北京 说:

设定单一接口，严格执行变更流程，设定验收标准。

让客户明确需求目的，大量的时间，精力花费在无用的功能上，导致项目延期对他们也

是损失。

邓超-开发-上海 说:

个人感觉 要先把分散的需求集中化，把相关的业务单位召集在一起 先整理整体的业务

流程

提出一个合理化的建议，然后再来做系统的需求。

Microhui-PM-上海 说:

PMP 课上老师说过，项目主观是满足干系人满意，客观是实现项目目标。但是主观比

客观重要。这儿的干系人没搞清楚，所以需求收集的不准确。

老张-技术总监-bj 说:

需求，先由甲方评议后，统一有接口人 open 出来，并定义优先级和验收标准。

标准，一开始就很难定义清楚，需要逐步明确，现在基本上是死一个项目经理的代价，

坚持了这么长时间，应该可以谈验收标准了。

谷雨霖 说:

这里面我个人认为有这几点问题：

1）集团需求引导不到位，要通过咨询来确定总体和分期目标，限定到小范围；冰冻三

尺非一日之寒，信息化建设需要徐徐渐进，不可能一步到位，更何况，人们的意识可能离成

熟还早的很分期开发对项目收款也是非常有帮助，不能将运营类内容，放到项目系统中来，

否则固定价合同只有死路一条。

2）在子系统发中，要设定标准，减少定制化（争取非固定价格合同）

所谓设标准，这对集团公司非常有意义，特别是国有集团公司。在集团公司做人是第一

位，做事是第二位，所谓责任第一，无责原则下才做事。那么如何才能无责做 IT 建设，就

需要树立标杆这个标杆一定是整体利益最大化下的产物，然后以此号令诸侯，杜绝或者限定

子公司的个性化需求。个性化需求不符合标杆，就是触动利益线，就是要担责任。通常，大

家都会收口。不收口，也会限定需求，或自己额外付费

项目案例

实践 健康 创新 家园

3）乙方虽然是内部子公司，也不能一味的接受放大的需求，学会说 no

说 no 的原则参考第 2 条

4）乙方的供应商项目经理，对变更需要推动执行，即便有了标准，项目过程中有需求

变化是非常重要的。我们不能拒绝变更，要适应变更。适应什么？

A． 将所有变更流程化

记录、审批、备案，有了这些变更，至少可以在一揽子工程中表达，乙方所做的工作量

努力和态度。

B．业务人员疏导性沟通。人七情六欲，提出些变化太正常了，业务人员要将这些变化

尽量扼杀在原始状态，至少是打折扣。

5）做好上集团项目利益链客户关系持续梳理，客户也在发展，乙方更需要与时俱进。

处事乾坤要懂点

马兆林-cio-京 说:

我觉得，说回来 ，甲方的 Tq 很重要，解决这个问题，开发事半功倍。

谷雨霖 说:

甲方的人能否进来，能否影响的到，这个需要遇到明白人，遇到官本位的甲方，这个过

程改进仅属于技术范畴，无解。只有在势层面分析透彻，设定合理的标准（不见得上来短期

就能搞定），道就有了。余下的，客户经理、PM 只需要做用方法执行好了。

有需求就有解，不在签名谈透、设定好，后面很麻烦。

老张-技术总监-bj 说:

从乙方来讲，这一项目就属于谁都不敢碰的项目，这一时候，标准每人谈，甲方不积极

参与

甲方也一肚子气，干了这么长时间，拿来一堆什么东西

Microhui-PM-上海 说:

我觉得这样的项目，分阶段做比较好，需求谈清，优先级高的先做。 这样的想法对吗？

马兆林-cio-京 总结：

企业信息化首先要规划。IT 规划前提是业务规划，一个客户没有业务规划 IT 不要碰，

碰则死。然后 1，2，3 期做什么？这个可以作为判断是否合作的前提。 糊涂的目标，没有

好结果，有规划了，需求的大框架就有了，也就是我们讲的业务流程边界有了。

恺墨-CTO-北京 说:

1 项目经理轻敌

2 上级领导没有重视

3 选择了错误的攻击点

4 火力不够强大

项目案例

实践 健康 创新 家园

急救措施要果断

Microhui-PM-上海 说:

我也想知道：

如果你是现在的项目的 PM，该怎么办？

如果你是空降的那个，估计就是第二个死的 PM

超-技术负责-深圳 说:捋顺关系，掌握手里现有的资源吧。

老张-技术总监-bj 说:

措施一：暂停开发，分析现有需求哪些已经实现，哪些未实现；

措施二：看看手边资源哪些还能用；

措施三：确定需求搜集机制。

由甲方对未实现需求进行排序，确定开发重点，每周定期搜集并讨论需求，每周发布一

次。

恺墨-CTO-北京 说:

我会重新火力侦查，调整进攻点。先确定老板还有没有决心支持，没有老板的支持，

趁早收手。

谷雨霖 说:

这个项目需要做个项目现状报告，乙方高管和甲方做深入沟通，看能否争取费用。如

果做不到，失败是必然。

马兆林-cio-京 说:

先看目标偏离，然后看看人力资源，不要逞能，首先判断项目有没有继续的意义。

及时沟通很重要

超-开发-上海 说:

个我的想法：把需求重新整理，然后标明是谁提出的，然后定期公布给项目的干系人。

因为大型企业里面，提出需求的人 有时候会担心有责任的问题，通过把需求公开化，

来控制他们各自的需求的边界。

Ted-项目经理-北京 说:

这个项目需要乙方高管和甲方高管好好谈一谈才行

一般甲方的高管还是很明事理的，下边的小兵都很难缠

马兆林-cio-京 说:

我做项目经理时，发周报发给项目所有参与人，让大家知道他们的需求开发到哪一步了，

不会存在任何信息死角。

周报的发放对象，从董事长到 基层甲方业务人员，这样大家都看到进展，成就属于大

项目案例

实践 健康 创新 家园

家。

还有就是签字制度，在于坚持执行，需求，验收都签字。

Microhui-PM-上海 说:

项目的成功与否，跟一个优秀的项目经理有很大关系， 马总做到的，只不过是 PM 的

基本素质-沟通，但它占的比重是 85%

老张-技术总监-bj 说:

关于需求沟通，需求提出人、甲方接口人，乙方接口人，乙方开发人，需要宣讲、Review，

最后才敢签字落实，双方沟通无误，是需要技巧的。

超-技术负责-深圳 说:

对，要落实下每个阶段的成果，然后周报展现，每个人都知道项目的进展，这样的东

西甲方看的也觉得实实在在，尤其是国企 ，有时候他们是需要政绩和实物来说明，他们也

要跟上层汇报的。

案例二：企业项目中的技术决策

主题：企业应用软件开发项目中的技术决策

导入：

企业级开发与其它软件项目如通信、互联网相比，有几个不同的特征：

1. 它直接面向客户；2.它有不亚于软件开发本身的业务专业深度；3.所以，客户

与开发团队在对同一问题上强烈的认知冲突是直接产生的，面对一个项目要正常地进行

下去，首先就要解决认知上的冲突，作为技术决策者，需要平衡各方面的因素。

第一个要抓紧的东西是：计划和进度——在这个项目里，先做哪些部分，再做哪些

部分，每个部分完成的里程碑在哪里。第二个要抓紧的东西是：团队综合技术水平，当

前能做什么，在接下来的时间怎样配合项目提高综合技术水平。

场景 1：设计决策，洞悉核心

一个遗留的供应商管理系统，数据库结构既定，程序既定，要实现一个供应商地址簿的

功能，查询却发现数据结构不支持多地址、多联系人设计；界面是 CS 架构，非常多的控件，

到处都在加载。这在开始时是一个很小的项目，预算大概就是 1 人 1 周左右的开发时间。怎

么做，如何做，它是技术决策中最初等，也是最常见的决策方案：主程序员决策。这个系统

的维护团队（负责所有新需求的开发）的主程序员根据需求，设计了一个地址簿模块程序。

那是一个很炫的程序：它有卡片式的名片翻查，客户非常着迷，决定就这样办。而项目是按

开发时间收费的，所以，这个设计是有利于团队的，因为客户愿意为它增加预算。这样，因

为技术方案，项目的规模扩大到了约 2~3 周。但在开发时发现，旧的程序框架使用的数据持

久化方式和绑定数据的方式太不灵活了，它是基于 DataSet 的，需要进行很多的编码；另外，

旧的控件呈现方案也不利于卡片的展现。这时主程序员决定对整体的数据库持久方案和界面

呈现进行重构，改写成更灵活的 OO 方式。最终的编程模式定义为 Observer Pattern——观察

者模式。在这个方案敲定之后，项目经理与客户协商，延期至 1 个月，理由是原方案可以提

项目案例

实践 健康 创新 家园

供更好的业务功能扩展性，因为客户对旧的程序运行速度也忧郁很久了，于是客户同意了。

经过大约 2 周的编码，提交了测试版本，期间遇到的问题是：测试人员不知道如何做测试用

例，因为没有定义好的功能，没有每个细节的界面。这些东西都在主程序员的脑子里，而主

程序员忙于开发，没有时间与测试进行沟通„„测试唯一能得到的东西就是随着开发的进度

与主程沟通，查看主程机器上运行的程序。2 周后提交了测试版本„„意想不到的问题产生

了：许多业务逻辑丢失了，此时据 QA 的报告，这期间大概提交了 3 万行代码。

绝大部分业务逻辑的丢失是因为在修改数据库持久化方式时对旧代码没有吃透造成的。

旧代码中实现由于历史原因，程序经过多个人手，会有很多重复性的但又有细微差别的代

码，这些不经过调试是无法直接判断是否可以丢弃或复用，此外就是对业务本身的理解深

度不够，原理、业务流程的缺乏，应该是企业项目中比较常见的陷阱。

接下来这个项目就上演了项目中最常见的一幕：项目经理问：

如果再加一个人，需要多少时间？如果再加两个人，需要多少时间？

又花费了大约 1 个月的时间，项目最终得以完成，幸运的是，客户很 happy。那个季度

项目组得到了历史最高客户满意度，付出的代价是连续几周加班到凌晨 12 点，但噩梦还没

有完„

对项目组的每一个新成员来说，噩梦就是学习这一套深奥的代码„„从此以后客户每次

提出与此有关的需求时，这个噩梦就开始上演。

大部分人都看不懂设计思路和调用关系。这个案例，就是一个典型的由主程序员作出的

基于纯技术决策的例子。

插播题外话：关于业务逻辑丢失

龙小宝-pm-bj 说:

我们也有这样一个案例，Java 开发的 B/S 模式的业务系统，什么 EJB 的实体 Bean,Session

Bean 都用上了，类继承从 4 层~12 层不等，一般是 6 层。少数 4 层和 12 层，根本没人敢改。

马兆林-cio-北京说:

根据表述，我觉得，第二案例这时解决冲突的方法， 甲方 IT 项目经理 应该站出来 协

调 2 个乙方协同的时间表 甲方主导 也只有甲方 PM 适合主导 我经历过 3 个供应商的，背

后是客户 3个领导的博弈。 但公司的利益第一，任何背后势力在 PM面前都要低头。 否则，，

第二案例肯定失败。 这和甲方的公司文化相关，也许能接收博弈的代价-项目失败。

马兆林-cio-北京说:

技术决策者的定义： 是 PM，善于流程梳理的 PM，pm 是个综合岗位，需求分析和对

业务流程的把控是能力的一部分

项目案例

实践 健康 创新 家园

场景 2：技术决策，“活在当下”。

接下来我们看第二个案例吧，它是一个很大的平台，由两家供应商公司开发，各自负责

一部分，最终进行功能上的集成。

这是一个外包项目，项目经理、需求分析师、开发团队 1、开发团队 2 都来自于不同的

公司。大家都有自己的算盘(rotfl)都想取得利益最大化。

计划和进度，就决定了交付压力和客户的反馈，这都会影响到各家的表现。

首先，客户有自己的计划表，这来自于他们的 IT 规划；其次，项目经理有一份计划表，

这来自于各个资源的到达时间和完成速度；再次，需求分析师也有一份计划表，这来自于他

约见需求确认对象的日程表„„

这个冲突持续了三个月，在三个月内，项目几乎没有任何进展，客户每次都在催问：什

么时候可以看到系统？

其实系统连个种子都没有„„它是一个全新的项目，谁都不知道它该长成什么样，从业

务应用上来说它也几乎没有可参考的，这是一个关于资金的投资计划的系统。

技术是什么？不是最终写出来的什么代码，使用了什么框架，而是针对客户业务的技术

解决方案。

需求用例不足以形成一个系统，就像“制冷需求”无法设计出冰箱一样，它只会说有冰

棍或食物需要冷藏，但多少摄氏度，需要几个门、有没有抽屉、隔板用什么材料、制冷加不

加氟利昂，用户需求能描述吗？

这才是技术的核心，技术不是编码，就像冰箱的制成方案不是工厂组装一样。需求用例

是用原型法来定义需求，它是方法，并不是需求本身。在这个项目中，首先要解决的问题，

就是为客户定义他们需要的是一个什么样的系统，业务需求和规约都是后面细节上的问题了。

这个“什么样的系统”问题回答者，项目管理范畴做不了，需求分析的范畴也做不了，它需

要的是一个技术决策者，无论他正处于什么样的职能。这个问题被回答了，事实上项目的范

畴和需求分析的范畴才真正确定下来。

在企业项目中，在有全新的需求时，谁应该去回答“开发什么样的系统”？这个问题你

们有没有答案？

那就是一群人来回答？

一群人的结果就是这个案例的前三个月，没有进展，项目面临全体下课。

这个问题本身是一个业务问题，因而业务需求的提出者更可能适合回答这一问题。

甲方的 PM 应该最了解自己要什么，或者经过市场调研后，定位于接近的产品，无非

就是 ERP，CRM。

还是可以归类的，之所以不是组织的原因也在于：单个供应商从能力上几乎无法承担这

样的项目 。甲方的情况是，他们是一群投资预算小精英，对软件甚至业务流程一无所知，

“甲方 PM”的概念更是无解，他们会回答：雇用你们 PM 就是做项目管理。他们只会用这

样的方式来解决问题：你们做不好，谁做不好就换谁，换分析师、换 PM、全体做不好就换

供应商。

项目案例

实践 健康 创新 家园

他们是不愿意参与到项目实务中来的是的，风险很大的项目，所以才拉了一群来共同承

担风险。这就是所谓外包中“背靠背”的方式，不知道你们是否很常见。

大部分技术人员包括架构师在遇到这样的项目时，采取的姿态都是被动等待。等待需求

文档。他们没有意识到，这时候最需要的就是一个能够构建系统的人参与进来，为客户提供

系统方案。承担这个角色的应该是一个有丰富经验的系统架构师。

首先需要了解的是客户为什么有这样的需求。

客户产生这个需求的原因是他们做了投资预算之后产生的后续业务已经有系统了。

他们做为这些业务系统的部分权限使用者，发现许多功能是残缺的，没有他们想要的功

能，没有想看到的数据。这个后果是肯定的——因为那些业务系统又不是为他们开发的，只

是它的所有业务部门为他们开放了部分权限。作为甲方的几个部门，他们采取的第一个动作

就是去争夺这些已有的系统，他们认为这个系统应该属于自己，然后就开始了高层领导的

PK„„

PK 的结果就是继续 PK 并且立即雇用一个团队来把那个系统改成自己想要的样子。

在前三个月，需求分析师和项目经理的时间基本上都花在说服原系统的业务部门接受自

己雇主的需求修改上了，这时候架构师参与了进来，初步达成的意向就是新开发一个平台，

使用共享中心业务数据库的方式来实现数据共享，就是这样简单的一个改变，直接就把两个

部门的争执平息了，这时候雇主部门才意识到自己需要的东西是投资计划平台，接下来就简

单了，大家一致朝这个方向前进。

企业项目从最开始，它表现的不是一个技术问题，而是一个愿景或业务问题。

这个实现非常简单，但定义它是一个什么样的技术问题本身不简单。

大部分项目都是扑朔迷离，如果技术人员从需求分析师、PM 那里被动传达要求，而不

是与客户坐下来讨论问题，最后的技术方案一定会失败。

SO，这个项目进入了正式的开发计划，又遇到了新的大难题。

客户在很高兴的情况下向领导一汇报，然后领导提出了自己对这个系统的需求，这时候，

客户就要求首先开发领导的需求了，整个项目计划表被全部重排，领导的需求就是报表。此

时的情况是：系统都还没有，怎么办？整个团队刚刚才坐稳屁股，这时候最不敢惹客户。此

前领导还在前方 PK 这时才真正开始提业务需求。

解决一切问题的根本就是从实际出发，没有任何凭空产生的问题， 领导需要看到的报

表，其实是当前就有的，只是它是以员工通过 Excel 编辑产生，既然现在有了系统，大家自

然会把这个功能放在系统报表里。

当前最好的技术解决办法，就是着手设计报表专用的数据库，将已有的 Excel 数据导入，

然后从报表数据库中产生报表。这个技术方案与整个系统设计方案只有 1 个关系，就是报表

数据库，这样不共享任何东西，便于分别独立开发，同时也分清责任。这里对报表数据源其

实有三个方案：1.业务数据库 2.报表数据库 3.数据仓库

业务数据库的难点在于，需求细节不清楚的情况下无法做设计，粗糙的设计即使满足了

报表需求，未来的变更影响所有的开发和报表程序本身数据仓库的问题在于客户需要采购新

项目案例

实践 健康 创新 家园

的软件，对开发人员有新的要求，以及预计的数据规模不大。

最后就采取了一个中间数据库专为报表开发，既支持读取存储 Excel，也能从以后的业

务数据库同步数据。

这个方案又押对了宝，仅仅两周就开发结束，并且期间不断与客户互动，客户整理数据

不亦乐乎，建立起了信任关系，接下来，开发团队分了一个人手，专门在每周维护 Excel 的

数据导入，其它人进入系统开发直至上线。项目出现什么差错都不是大问题了，客户越来越

好说话，最后的结果是整个系统的报表处理技术在不断升级，而已，项目圆满结束。

关于需求本身，他们说：

陈加兴-研发经理-成... 说:

第二个案例是一个基于业务的技术决策，它是典型的“活在当下”。

许多谈话中的决定性细节，需求人员和 PM 缺乏技术敏感性，除非客户需要的不是一个

技术方案，技术敏感性的缺乏是致命的，比如：错误的计划表、错误的工作量估算，大部分

需求的记录是从客户的角度，而不是系统开发所需要了解的全部需求。

wenjin.xu-IT Cons... 说:

这在中国某些政府项目中 特别明显, 政府项目的乙方喜欢拉上 IBM,MS 等一流公司陪

绑,如果出了问题可以由他们背黑锅,(或间接证明项目没法做的,你看人家世界一流的公司都

没做出来)

马兆林-cio-北京，新... 说:

我经常讲，软件就想盖大楼，干什么大楼没搞清楚，我是不盖的。这个大楼是酒店，工

厂，民宅？是仓库？你先给我讲清楚，图纸我画给你，厨房什么样？马桶在哪，必须签字确

认！如果是大型高级应用，甲方应该配备自己合格的 PM，完全交给乙方，风险不可想象。

从 case2 的“投资计划平台”定性看，不是 IT 问题，是甲方开始想通过乙方 回答自己

要什么，但前期代价很大，很幸运，乙方来个解惑的 架构师。 但架构师真的不是 解决“投

资计划平台”定性的途径。 也许这个架构师炒股或者做过会计，投资项目，否则这个问题

还解决不了。 甲方的出发点错了。乙方为了争夺项目 做了很多无用功。 社会资源的浪费。

所以后面的报表开发的问题出来了，这个实施商根本可能就没有相关经验，一个架构师不是

一个实施团队。

wenjin.xu-IT Cons... 说:

需求方面 应该是乙方去采集,甲方一般没有系统的概念, 需求分析人员要承担需求分析

的工作, 初期技术人员只要确定技术可行么?能实施么? 时间要多久这些专业方面的建议。

而且在初期需求不确认的情况下,给出的工作量必然也是有误差的,这要随着需求和文档

的进一步细化才会越来越精确。

这就是分析人员要有技术背景,或者要有技术人员在早期参与评估。

Michael-PM-厦门 说:

技术决策首先需要完整、准确收集需求，其次需要一个经验丰富的架构师或需求分析师，

最后给出一个经济、适合的技术方案，对项目负面风险影响最小的方案。但是，当下究竟是

项目案例

实践 健康 创新 家园

一个什么样的问题，这个问题定义本身就是一个技术活。在开始，它是一个迷团，你唯一能

听到的就是持续不断的争吵声，随后就是各方面施加的压力。

这是最考虑一个决策者的部分。需要让各方冷静下来，让各方都满意。

具体到需求收集：一、甲方的项目发起者或者说领导的推动力不够，二、项目的组织角

色、责任需要明确，三、无论是任何项目，甲方都不可能摘出自己，因为再有经验的乙方架

构师都不可能凭空给出需求。

这完全是需求的问题, 乙方需求人员没有帮助甲方确定需求，确定什么是乙方想要的，

确定什么是甲方想要的。

在需求问题上，甲方需要做两件事，一是配合乙方收集需求，二是拍板签字；而乙方要

做的是把甲方的愿景转换成技术的、可描述的、可执行的具体需求。

泳菲-pm-北京 说:

我经历过类似的情况，甲方老板想做一个项目想了很久了。然后就是甲方各个部门的讨

论与博弈。

讨论了一年，没有任何动静。需求文档出了很多版本。但是系统什么时候开发一直也没

定下来。后来，公司来了一个项目经理，了解情况后，不在组织任何的讨论与扯皮。对原来

讨论的文档研究了一下，立即组织开发人员开发 DEMO。一个月后。DEMO 获得老板好评，

项目资金马上到位并开始开发。最后结果是，老板大力支持项目。原来很多扯皮的部门与领

导也不得不出来支持。很多原来扯皮的矛盾渐渐化解。

现在很多项目就是这样。如果要把需求讨论清楚。项目就是无法开工。

兔子瞧-PMO 顾问-北... 说:

我觉得更致命的是分析的时候对业务缺乏框架思考的能力。只要框架不设计错，技术上

不会有太大的问题。现在很多需求设计人员只会需求功能的分析，而不是业务设计。

这个时候还在评估阶段, 技术人员要对技术风险,现有团队 开发时间等作出较为准确的

判断, 不然后面就惨了。

蔡德辉-PMO-大连 说:

不管在什么情况下，在需求方面，客户、开发商之间要良性互动，用客户懂的方式，描

述业务需求，或者实现业务需求；用设计人员懂的方式，描述技术需求。至于技术的决策，

如果是做应用，应该是比较快的，当然建立在有经验的基础上，但不追求过分的完美与细节。

这种局面 99%的解决方式都是抛弃所有局内人姿态，因为他们本身就已经在冲突了，不

换思路只有继续冲突下去。

场景 3：挑战新设计 比较成功

这里的技术决策是企业项目，是有一个背景的。背景不同，影响决策的因素就不一样了。

好，我分享第三个案例吧，这个相对比较成功。它是我现在在做的项目，带领一个团队

用完全不熟悉的框架和设计思路做事，包括 ORM、容器、TDD、DDD 等，技术决策者需要

的是专业，还有权力，没有权力，就得运用影响力，否则是谈不上决策的，那只叫发表意见。

项目案例

实践 健康 创新 家园

对开发中常用的框架，其实企业项目运用到今天，已经非常成熟了，决定要快，学习要

抓，遇到问题强调相互解决，就会产生一个上等的决策结果。实质就是不管你选择哪种框架，

路都是可以走通的，这个“技术”不是核心。其次就是开发中采取的开方思想，比如 OO、

TDD、PP，开发思想或编程思路，我认为它是程序员个人化的东西

它无法“被决策”，为什么？因为不懂的人，无论如何都做不了。钻木取火、火柴、打

火机都是点火，不必强求。当然成功点火的时间都有差别就是了。对，如果要使用不熟悉的

东西，需要有一个学习计划表，但是思想很难被学习，需要一定的理解能力。所以才有这么

多的框架，框架使用起来很简单，但你让程序员描述 spring 中各个设计思想，然后让他们自

己实现，就非常难，与个体强关联的部分如何做决策？答案是：因人而异。对软件开发来说，

做到一致的代码编写规范，模块划分合理即可，这个是任何程序员都能够做到的。

关于技术决策时考虑因素：

1．任务紧急时，要抓紧的东西是：计划和进度——在这个项目里，先做哪些部分，再

做哪些部分，每个部分完成的里程碑在哪里；

2．重构代码时，要抓紧的东西是：团队综合技术水平，当前能做什么，在接下来的时

间怎样配合项目提高综合技术水平 ；这是一个技术决策者在作出正确的技术决策之前必须

了解的东西，无论它是正式的文档还是私人的交流，它都必须准确真实、第一手。如何去获

取，自己想办法。

技术决策的几种常用方法：

1.主程序员决策：由团队中担任主力设计或开发的人来决策；

2.效率高手决策：由团队中完成任务速度最快的人来决策；

3.矩阵式决策。

每个决策方式都有特定的场景，具体的应用还需要根据实际情况灵活应变。变是永恒，

适者生存。

Michael-PM-厦门 说:

无论是谁来决策，都必须通盘考虑，不能从自己能力出发，因为别人有可能达不到主程

序员的水平，也没有效率高手那么有效率。

PM 成长

实践 健康 创新 家园

PM 成长

我的项目管理之路--项目（FBMS） by- Husthxd

本文写于 2005 年 12 月，由于某些原因未能公开，现在一晃过去 N 年，早已物是人非，

回头看看这篇文章，当时的情景还是历历在目，让人感慨良多，用一句时髦话总结：“很傻

很天真”。不敢独藏，与各位同行分享。

本文可以任意转载或分发,但请注明作者和出处。

该项目是 X 财政局的预算管理系统，与 7 月 1 日上线的国库集中支付系统在同一个平台

上。国库集中支付和预算管理是财政的核心业务，幸好，偶们今年都一并做了。

5 月份中标，到 9 月初历时 4 个多月，但项目真正启动是在 7 月 4 日，当时部门的高层

判断失误，错误的以为这个项目可以延期到 10 月中，结果大家都在拖，同时由于国库系统

没有做好，问题不断，也影响了预算系统项目的启动。一直到 6 月底，财局的局长一个电话

打到大 boss 那里，要求跟他谈谈。那天 下午的会议开了 1 个多小时，最后的定论是预算

系统项目不能延期，一期（单位版）必须在 8 月 15 日前上线，二期（财局版）必须在 9 月

5 日前上线，当时离 deadline 满打满算只剩下两个月时间了。两个月，做一个从来没有做过

的业务系统，没有人熟悉业务，使用并不十分完善、前台开发效率很低的 j2ee 平台，可能

完成吗？我没有信心，客户也没有信心。“你们能在 8 月底完成吗？我们的兄弟评估过，你

们很大可能不能完成。”客户不止一次在偶面前说这句话，我当时只能苦笑，因为我也不知

道能不能完成。

面临的困难很多，如何能够在两个月时间内完成这么一个项目？我们还是一步一步的来

看看把。

项目组在项目启动之日（2005 年 7 月 4 日）成立，当时的项目组的组成有 PM、QC、 TM

和 QA 各 1 名，高级程序员（其中一名从公司其他部门借调过来，时间到 8 月底）2 名，中

级程序员 3 名，初级程序员 2 名，还有一个 mm（需求人员/集成测试人员/文档编写人员）。

幸好，项目组中有多名团队成员参与过第一个项目（国库集中支付）的开发，积累了不少的

经验。

项目采用跌代的开发方式，其中一期 beta 版本在 7 月底发布（以提交给客户做评审为

标志），release 版本在 8 月 15 日发布；二期 beta 版本在 8 月 15 日发布（同样，以提交给

客户做评审为标志），release 版本在 9 月 5 日发布。从最后的结果来看，当时错误的估算了

二期的 beta 发布时间，直到 8 月 22 日（其实这个时间发布 beta 版本客户也应该是接受的）

才发布，延期一周。

为了规避需求风险和技术风险，7 月 4 日－7 月 8 日，需求开发人员天天缠着客户（mm

就有这样的好处了，换成个大男人天天缠人就不太好了）确认需求，同时组织技术评审，定

好大体的开发和技术框架。

由于不熟悉业务，只得采用驻客户现场开发的方式，但有些团队成员（1 高级程序员，

2 中级程序员）有其他任务在身，不能在客户现场开发。迫不得已，安排他们在广州开发一

期，项目组主力驻客户现场开发二期，分为两条开发主线并行开发。当时错误的估算了一期

的工作量和高估了广州开发人员的能力，在 Week1 结束后（7 月 15 日）发现广州开发小组

只是做了几个还没有完善的 jsp 页面，其他什么都没有，进度已经严重滞后。当时分析的原

PM 成长

实践 健康 创新 家园

因有那么几点：

1. 广州那边的开发人员没有参与第一个项目的开发，技术积累不够，业务知识积累不

够。

2. 由于需求是在客户现场捕获的，通过 msn 等交流工具存在很多的沟通问题。

3. 开发人员的能力确实不够，短时间要求他们的生产效率大幅提高不太现实。

4. 迫于时间的压力，没有做技术框架的 Demo 和完善的架构文档以及技术说明，直接

导致了代码的不规范和实现方式的不统一，直接影响了一期的开发效率和进度的滞后，因为

一期的开发人员大多是新手，希望他们几天时间了解 struts、dao 等等确实是勉为其难。

一开始就延期了，怎么办？最直接有效的方法，加资源，冒着二期可能延期的风险，抽

调了一名中级程序员小 C 到广州开发一期。结果 week 2 结束后（7 月 22 日），一期的开发

只完成了不到 50％，这时候离发布一期 beta 版本只剩下 5 个工作日的时间。当时的直觉：

一期如果还在广州开发就必然会完蛋的，当机立断，决定广州的开发截至到 26 日，同时 26

日开始广州那边抽调一名初级程序员并和原来抽调过去的小 C 在客户现场开发一期，同时以

外包的形式把一大部分的内容给 WBB 开发。这回把宝压在了 XXX 上面，幸好，偶没有看错

人，WBB 没有让我们失望，经过一个星期的努力和周末的加班，一期 beta 版本在 8 月 1 日

如期发布，先在客户的技术部门内部做了一次评审，并在 8 月 4 日给客户的业务科室做了一

次演示，谢天谢地，演示过程没有出错。真的已经很稳定不会出错了吗？当然不是，在 3

日晚上内部测试的时候就预先把那些功能可用，那些不能用，那些按钮可以点，那些不能点

搞得清清楚楚，以确保演示的“万无一失”。

演示 Pass 后，经过 QA 的测试，在 8 月 15 日发布了一期的 release 版本 1.0。当时还很

乐观的认为一期不会有什么问题，但后来几天发生的事情，让我自己都觉得这个版本实在太

烂了，出现了很多很多不该出现的缺陷。因为什么？没有代码复审，在上线前如果我花 1-2

个小时的时间，认真看看代码的话，起码可以保证不会出现一些很严重的问题，也不会弄得

客户的电话变成热线，一刻都没有停过。比如，一个非常严重的缺陷，单位 A 和单位 B 同

时做业务 C，单位 B 的用户后登陆，单位 A 保存数据后，这些数据都变成 B 单位的数据。

Why？客户带我们去客户的客户那里看现象的时候，我也不相信，怎么会有这样的情况发生？

重新看代码，发现了某些可疑的代码可能会导致这样的问题，修改后重新发布。当时有一个

很可疑的变量，我感觉是有问题的，但一时忽略，没有细看，这是基于：开发人员不会犯这

么低级的错误的。结果到了第二天，还是有这样的问题，这回用了不到一分钟的时间就发现

struts 的 action 类中居然出现了静态变量，这个变量用来保存单位编号，也就意味着某个时

刻只会有一个单位存在，其他单位做的数据全部都是这个单位的数据。我 Kao，这个错误也

太低级了，实在无话可说。

另外还有其他一些小问题，页面问题，操作不方便问题，那段时间客户的电话没有停过，

而且往往是一个电话过后，客户就在我身边跟我说这个有问题，那个有问题，接着又匆匆跑

回去接电话，然后又匆匆的跑过来跟我说这个那个，那 1-2 天真不是人过的日子，连喝水的

时间都没有，幸好，客户关系做得还算可以，压力都顶住了。然后，电话慢慢，慢慢的少了，

一个星期后，每天只有零星几个电话，多数是操作问题。

总的来说，一期是硬上的，没有经过 QA 的严格测试，没有客户的试运行，没有 SA 的

代码复审等等，质量可想而知了。不过我们都挺过去了：一切终须过去，只要奋起面对。

相比较而言，二期的质量就好多了，毕竟是项目组的主力完成。二期的开发是跟一期同

PM 成长

实践 健康 创新 家园

时进行，在客户现场，这样做的目的是把客户的资源也纳入到项目组中，客户的信息部门有

一个既熟悉业务也熟悉技术的人配合我们。一个很不爽的地方，由于客户地方不够，我们只

能跟客户同一个办公室，什么事情都暴露在客户的眼皮底下，cvs 等等重要的资源也是跟客

户共享，这个非常的不好。当别人对你知根知底的时候，想跟别人讨价还价就很难了。另外，

不得不说一下的，财神爷又不是没钱，却在硬件方面小气得很，Web Server 用的还是 1 个

CPU，1G 内存的机器，而且数据库还是 Sybase 11.9.2 这样的古董。先不说这些废话了，看

看二期的管理把。

首先，最重要的先把范围定好，跟客户确认在 2005 年 9 月 5 日上线包括的内容，这方

面经验不足，其实有很多可以在 9 月底上线的内容都提到 9 月 5 号，但客户一口咬定非得在

9 月 5 日上线，现在想想，实在不知道客户方出于一种什么考虑。其次，定好范围后，拆分

模块根据团队成员的特点分配工作，比如新加进来的开发人员就分配一些不需要熟悉业务的

工作，参与过上个项目开发的就分配一些熟悉业务的任务等等。其实加快任务的执行最有效

的方法就是拆分为并行的多个任务，而且这些任务相互之间的关联越少越好，这个跟 Oracle

并行执行的原理是一样的。

二期开发一周（7 月 16 日）后，发现项目组的前台开发效率很低，项目比预期延期了

20%。效率为何低下，当时分析的原因有：

1. 项目组成立没多久，团队之间的磨合不够，基本同一班开发人马，加入的人员又是

新人，要想在短时间内，提高开发效率是比较困难的

2. 开发人员的能力不够

3. 对于现场开发的开发环境，不利于团队建设和人员沟通，由于和客户混在同一个工

作场所，人员的士气会受到影响、交流的机会大大减少

当时在进度报告中对这些情况作了详细的说明，要求增加 1 名熟练的前台开发人员开发

新的业务模块以及熟悉 Sybase 的后台开发人员 2 名开发查询统计部分〔如果目前资源不足

以完成任务的情况，PM 就应该跟高层要求资源了，不然 PM 没有跟高层说明情况而导致项

目延期的话，老板会很生气，后果会很严重，责任会很大〕。报告是发过去了，不过高层那

边好像稳如泰山，不见一点动静。当时感觉是部门没有资源可用了，项目已经存在延期的风

险，起码 beta 版本的发布会受到很大影响。幸好，在第二周，新加入的高级程序员小 W 的

开发效率提高了很多，这是一个很利好的消息。在第二周结束后，小 W 开始了新业务模块

的开发，但查询统计还是没有人开始做，需求开发、代码开发等等，还是原样。

这样的开发一直到了 7 月底，这时候由于一期要上线，中间抽调了不少资源在一期上，

在 8 月初的第一个星期，感觉特别的乱，一期开发和二期开发扯在一起，那段时间基本上没

有计划的，内容实在是太多，人员安排不过来〔不要跟我说加人，这时候加人只会更乱〕。

幸好，也只是一周的时间，慢慢的，从混沌又恢复到正常，这是在一期上线后，也就是在 8

月 8 后。

这时候，又加入一名新人小 Y，据称熟悉 Sql server，熟悉存储过程，加入项目组开发查

询统计。不过一天过后我就觉得，如果单靠这个人的话，查询统计两个月都做不完，技术不

太熟练之余，业务上的理解有不少问题。负责开发需求的人在跟我提意见，说小 Y 应该这样

开发，不应该那样开发，偶只是听，没有做其他实质性的工作，因为我知道单凭他是不可能

完成任务的，反正都要延期，不如先集中精力把其他有望如期交付的任务上面。这种情况也

如实往部门高层反映，并抄送了一份给大 Boss。不知道是客户给 boss 施加了压力还是什么

其他原因，大 boss 派了一个玩了八、九年的 sybase 人 CF 过来，当然效率不是小 Y 可比拟的。

PM 成长

实践 健康 创新 家园

客户曾经说过，查询统计不能在 9 个工作日内完成，但 CF 做到了，而且是在周末没有加班

的情况下做到的。

终于，到了 8 月 15 日，还有 30%的工作量还没有完成。硬着头皮跟客户解释，结果没

说几句客户就开始埋怨为何不早响警报，为何不找他要资源，为何不要求他们的支持，说了

一堆。然后说到一期上面，外面一百多个单位，出现那么多问题，真给你们玩 s。说得我没

话可反驳，尤其是一期的质量确实不好，当时就抱定：没关系，说就说把，反正偶脸皮厚。

为了讨好客户降低压力同时也为了规避变更风险，在没有把握的情况下在 8 月 19 日发

布了二期的 beta 版本，并给信息部门做了一次演示。变更不多，就是本身的 bug 实在是太

多，bug 系统里面的集成测试计划和系统测试计划里面都有 2 个页面的 bug，总共有 100 多

个，经分析后，中优先级以上的有 60 多个，这些 bug 要在 9 月 5 日前全部完成，而且保证

不能出现新的 bug。当时都有点蒙了，这么多？在 8 月 19 日开始一直到 9 月 2 日，除了两

个人还在开发查询统计外，其余资源全部投入改 bug，这时候中级程序员和高级程序员的分

野就在这里了。高级程序员做出来的东西 bug 不多，修改起来也很快，而中级的呢？一堆错

误不止修改 bug 还改出不少 bug。当然，这个跟人的素质是有关系的。很不幸，项目组有这

样的人存在，而且在负责关键任务〔为什么？没有资源〕。终于，一天，偶实在是无法忍受

“修改 10 个 bug，5 个复审不通过，又引起 5 个 bug”这样的情况，让另外的高级程序员大

H 全面接手这部分工作，效果马上就出来了，bug 是越来越少。

最后，上线时间定下来了，无论如何，9 月 5 日上线。那就意味着，9 月 3 日（周六）

就必然要加班了，实在还有很多的 bug 需要修改。为了减轻点压力，9 月 2 日集 体去看电

影靓 Tom 的新片《世界之战》。9 月 3 日奋战了一天，直到晚上 9:30 才从 X 地回广州，在东

圃的农家庄吃饭，东西还不错，就是吃得太晚了，到家已经是凌晨了，感觉，真累。

9 月 5 日，一个值得回忆的日子，在没有延期的情况下，系统如期上线。辛苦了整整两

个月，总算有所回报。

PM 成长

实践 健康 创新 家园

我与项目管理

文 / 蓝叶菱

很早以前的故事----我不知道项目管理如何做项目管理？

就在五六年前，还是六七年前，自己还是一个公司的技术部门经理的时候，头衔很虚，

部门的兵很少，准确的讲就是道道地地的程序员，高级都谈不上，至少在部门的那些兵里面

算高手了。

由于我们单位的带有政府性质特殊背景，我居然有幸承担过 2000 多万的项目，一期工

程的硬件投入大约 800 万，纯软件的开发约 600 多万（实际到账不足 400 万），结果就是这

样，我啥都不懂，领导问我可以不可以搞？当时年轻，怕什么，不就是软件开发吗？什么硬

件部署吗？我告诉头说：小 CASE。当时我脑子里面啥项目管理的概念都没有，就这样，我

们承接了项目。

当时，我们编写硬件的方案，和网络公司合作编写方案，没有干过，百度帮忙，我和客

户的老哥很熟，他也是客户方的负责人，就这样我们就完成了方案，软件开发只有初步的概

要方案的稿子，需求调研，和客户一点一点的边开发边完善，客户（现在是客户部门的这些

职员都是我的朋友了）和我一起工作，当时工资不高，客户请客，饭吃的不错，至少我这个

穷人吃的胖了不少，什么加班，我们怀着打造全国最好的系统的思想，都在不断地努力着。

就是这样 1 年半，三大软件研发先后完成。其中一个中型业务系统消耗的时间达到 8

个月。

我非常投入，我身体垮了。项目在实施的时候，遭遇到部分用户的抵制，这些用户从来

没有摸过电脑，我们的系统包含财务系统，这就意味着政府单位的很多人的可观的灰 Se 收

入被剥夺了，但是高级领导层授权，就这样面对着都不知道什么是任意键的超级可爱的挑剔

用户，运行 1 年多，终于的到了客户的肯定。

这个项目当时同类的有北京的某上市公司做过，结果和我们的相比，根本不贴近客户现

实而被说成了垃圾。

后来，单位被政府收编，二期工程中的中型业务被另外一个公司被承包了，那个单位从

开发到最后上线，照着我们开发的样板，带领比我们多的团队进行二次开发，漂亮的需求分

析文档，居然研发了 1 年半多。

这个项目我们创造了神话，这个项目中我根本啥都不知道，不懂啥叫项目管理。可是在

这个项目中，我知道我的项目研发也没有达到极限，一直在思考自己哪些环节还能做的更好，

后来才开始接触软件工程、企业管理、项目管理。

为什么这个项目成功？第一：亮剑精神；第二：为了我们的目标，不断地排除障碍，（后

来学习 PM，才知道那个叫风险管理），第三：做好客户参与，没有写过需求文档，（后来知

道用了很多敏捷开发中极限编程的关键实践）。第四：不会的问题，CSDN,百度帮忙，一种破

实践才是重要的。知识的名词，知识，书籍的膨胀会让你感到

无奈，你有本事把书读薄，那个叫本事，越读名词越多，知识越多，

估计你这辈子都不会有尽头。 知识有界，智慧无界。

PM 成长

实践 健康 创新 家园

除各种难关的精神。

当然，还有很多敏捷的，这里不提也罢， 有成功的也有失败的，不过当时不懂啥叫 AP；

有失败的地方没有，当然有，就因为有失败的才让我后来学习和提高，开始思考怎么让

技术为企业服务，学习企业管理？

但是最后我失败了，失败的是，我的身体垮了，这个是最大的失败。

项目管理不是神秘得遥不可及。现在学习了项目管理，考取了 XXX 证，其实就是为了

工作，现在做的不如以前，因为我现在更多的是思考，失败的自己。毕竟那个不叫人生，人

生要量力而行。

风险管理是项目管理的最重要的核心之一。

现在来北京了，没有以前的热情，现在面对项目就是在思考，如何达到某种极限而已。

对于大项目也没有热情。

我面对的是成为职业项目经理人的思维转变的问题，不可否认我的思维停留在技术思维

里面。

6 年-7 年前，计算机语言还在讨论那个好?那个坏?架构还不知道走向何方，软件工程的

词还没有来到中国。

至少在中国中小企业里，CMMI 很多企业还在琢磨是个啥东西。

以上的例子，千万不要有错觉，只是告诉你项目管理是大众学科，没什么神秘高深可言。

和中国五千年的智慧，不值一提。甚至都不如买菜的企业家。有点谢永强回到象牙山的尴尬。

实践才是重要的。知识的名词，知识，书籍的膨胀会让你感到无奈，你有本事把书读薄，

那个叫本事，越读名词越多，知识越多，估计你这辈子都不会有尽头。 知识有界，智慧无

界。

当然，以上不是告诉你说项目管理知识无用，至少告诉你实践更加有用而已，学习是必

须的，但是思考和实践更是必须的而已。

切记，切记„„我从来不说项目管理，但是还是喜欢看。

理论体系

实践 健康 创新 家园

理论体系

挺敏捷 美猴王再闹天宫

——小议 CMMI 与敏捷之争

文／恺墨

自从阿波罗登月，将嫦娥惊出了广寒宫，那些不知天高地厚的凡夫俗子的供奉就越来越

少，而这天庭的日子则越来越清苦。没办法，玉帝只得派遣清虚道德真君、南极仙翁等各路

人马四处打探赚钱的营生。最后，还是如来佛祖神通广大，这不，赤脚大仙从如来那里请来

了一部《CMMI 无量大法》。玉帝如获至宝，谁想却引出一段公案。

话说那玉帝听得赤脚大仙从西天佛祖那里请得真经，立刻吩咐下去，摆香案迎请。接着

赶忙组织托塔天王率四大天王，各路神仙日夜研习。毕竟是神仙，悟性非凡，不几日就已娴

熟。于是，成立了天庭咨询集团公司，认证，培训„„，朝九晚五，依旧过那神仙日子，哪

管那凡间的软件项目经理，程序员键盘敲得飞快，码字码得天昏地暗。衬衫哪顾得洗，白衬

衫怎好意思穿出去，于是纷纷换成蓝衬衫，更有甚者索性黑色 T 恤，一身休闲，经年累月也

不用洗；至于汗味„„，简单，香水伺候，于是，香水产业生意兴隆，好不热闹！不想，却

惹恼了一位大仙。

这大仙，大家都很熟悉，出身东土，后追随唐僧西天取经，得成正果；不错，正是斗战

胜佛孙悟空。却说那悟空，取经后回花果山继续清修。那花果山本是山清水秀之地，近日却

不断有异味侵扰。寻源探底，原来如此！那大圣最是嫉恶如仇，眼见众生疾苦，凡间、天庭

转得一圈，心中了然，便知是缘起那《CMMI 无量大法》。心想：既是西土之物，西土当有

克法，待老孙西土一游，寻那破解之术。

说来也巧，正赶上西土也是闹得不可开交。由于不满《CMMI 无量大法》，业内 17 位软

件专家发布了《敏捷宣言》。那大圣虽不懂得什么软件开发，不过悟性却是极高，一看内容

梗概，便知是解决问题的法门。谢过了几位大师，索取了一套秘籍，一个筋斗云翻上灵霄宝

殿，递交了玉帝。

材料递交以后，迟迟不见动静。想那天庭繁文缛节，最是没有效率，怎奈凡间异味，实

在难忍，无奈，那悟空只得再上灵霄宝殿。

一问才知。原来，玉帝接着悟空的资料。却也不敢怠慢，急遣赤脚大仙去西土打探。不

久，赤脚大仙回报，那西土也是这般，只是一来已有几百年基业的底子，二来，仗着优势，

巧立名目，榨取东土的油水，暗自贴补本国居民，因此矛盾还不突出。不过，近来形势有些

变化。已有人打出“占领华尔街”的旗子，且大有席卷西土的趋势，形势也是不妙。另外，

CMMI 针对敏捷的凌厉攻势，竟施展吸星大法，有人呼吁双方相互拥抱，还在 CMMI 中加入

了敏捷的内容，值得我们参考。随后，还提交了一份调查报告。玉帝一看，言之有理，于是

照准各部执行。

大圣接过资料仔细观瞧，不看则以，看完真是怒从心头起，恶向胆边生，左扯右撕，将

那资料扯得粉碎，掷于地上，从耳中掏出金箍棒，这悟空，要再闹天宫！

“就这些？让他们闹去吧，关我们何事？”老徐（凡快，编者注）笑眯眯地看着我。

理论体系

实践 健康 创新 家园

“唉！我也是这么问的太白金星。”我接着讲下去，“金星说他们好不容易劝走大圣，想

来想去，这大圣不比从前，如今已是如来弟子，如来那里不好去理论。常言道，解铃还须系

铃人。既是凡间事，还要凡间人。也不知怎地，竟搜到咱们那本书，就把我抓了去。”

“于是，你就把我供了出来。你可真够朋友啊！”

“朋友嘛，当然有福同享有难同当！”我脸一下就红了，接着解释道：“其实，你也是逃

不掉的，在那本《IT 项目管理那些事儿》里，你还是主角呢！再说，塞翁失马焉知非福。”

“这也难怪大圣发怒。”老徐呷了一口茶，放下茶杯，侃侃而谈：“你想想，把敏捷纳入

CMMI 的方法和当初把他请到天宫当弼马温，看蟠桃园有什么区别？顶个齐天大圣的头衔，

有名无实。新仇旧恨，怎能不让猴王怒火中烧？”

“对啊！敏捷处处和 CMMI 针尖对麦芒，而 CMMI 却不正面回应，后来，干脆把敏捷纳

入进来，美其名曰‘拥抱敏捷’，明显是没有把敏捷放在眼里。这的确和当初玉帝封了猴王

齐天大圣，却实际并没把他放在眼里如出一辙。这么说，你是站在敏捷那边了？”

“大圣神通广大，悟性极高，敏捷的代言人是当之无愧。不过，敏捷毕竟发展时日较短，

再加上是轻量级方法论的专家创造，毕竟功力有限，以轻量级的方法去硬拼重量级的五行山，

不被压在山下才怪呢！”

“嘿！凡快，你这是哪头儿的？”

“《老子》中有：‘天下皆知美之为美，斯恶已；皆知善之为善，斯不善矣。有无相生，

难易相成，长短相形，高下相盈，音声相和，前后相随，恒也。’”老徐没有接我的话茬，而

是继续讲他的观点：“敏捷和 CMMI 看是针锋相对，必定也是相互依存的，相互拥抱应该是

趋势。只是现在 CMMI 拥抱的方式有些问题；敏捷一味对抗也不是办法。”

“各打五十大板，还真中立。当你是包公啊！”看着老徐沉思的样子，我忍不住调侃道。

“缺根筋！”这时，从我身后飘来一句。

我回头一看，原来是一位须发皆白的老者，显然，他一直在听我们谈话。“老伯，您怎

么这么说话？”

那老者微微一笑，竟不理会，站起身，飘然而去。

缺根筋就是缺心眼，有意见可以提，怎么张口骂人？真是为老不尊，我正在为老者的无

礼而忿忿不平。

“是啊！缺根筋！”突然听到老徐兴奋地喊了一句。

我一脸疑惑看着老徐，问道：“你，你„„，没事儿吧？”

“怎么说呢？你看，这敏捷和 CMMI 就像这手和胳膊：手指灵活，但是力量比手臂弱多

了；手臂力量大，可没有手指灵活。所以，手指有手指的用途，手臂有手臂的用处。而连接

手指和手臂的，不就是筋吗？我们不需要手指变成手臂，也不需要手臂变成手指，而是需要

筋将它们连接起来！”老徐竟然手舞足蹈地比划起来。

“原来是这样！那老者一定是看见你比划，才想要点拨你。嗨，我还以为他在骂我们俩。

你的意思是说，敏捷没有必要变重，把文档和知识积累，甚至人员的前期培训交给 CMMI；

而 CMMI 也没必要变轻，专心处理成熟的行业方案，把拥抱变化的部分交给敏捷？”

理论体系

实践 健康 创新 家园

“对！如果继续像现在这样：敏捷和 CMMI 互相抢对方的地盘，都恨不得将对方打倒在

地，企图一统江湖。最后的结果恐怕只能是敏捷不是敏捷，CMMI 不是 CMMI，都成了四不

像。”

“有道理！那，对于‘筋’，你是怎么想的？”我接着问。

“依我看，相对弱小的敏捷，之所以表现出好斗，还是因为 CMMI 的傲慢和咄咄逼人。

其实敏捷更希望得到 CMMI 的认可和支持，这样，敏捷就可以集中精力向更轻灵发展，敏捷

的特点才能得到更好地发挥。在这方面，CMMI 应该更大气些，调整心态，全方位地投入到

对敏捷的支持，而不是虚情假意地拥抱敏捷。要知道，当 IT 从供方市场变成需方市场，拥

抱变化已是一种不可逆转的趋势。那种一招鲜吃遍天的日子已经一去不复返了。这恐怕就是

老子所说的：‘反者道之动’吧？再有，敏捷实践中的知识积累可以为 CMMI 建立行业模型

提供充分有效的数据支持和经验，一个成熟的领域对敏捷来说，可以说是味同嚼蜡。就好像

唐僧喜欢参禅打坐，而孙悟空却更喜欢打妖怪；相反，成熟的行业更能 CMMI 发挥集团优势、

重武器火力的好机会。可以这样理解：敏捷不可能替代 CMMI 成为主流；相反，成就敏捷其

实是一个 CMMI 为自己开疆扩土的过程。而且鉴于目前 CMMI 的成熟和其在人力、理论研究

等资源优势，CMMI 方来作筋的主力是一个不错的选择，当然，要作好这方面的工作也需要

敏捷方面的配合。”

“对，关键还是一个理念，‘服务’。不过，针对互联网等需求变化大的领域，也可以考

虑敏捷为主，引入 CMMI。”

“CMMI 已基本成熟；敏捷一旦得到 CMMI 的力挺，结束两头作战的方式，真正解除后

顾之忧，也就摆脱束缚，会有更大的发展；未来决定一个企业营利能力的，恐怕就是这根‘筋’

的强度了。”

„„

“还有，敏捷现在的培训方式就像不从侦察兵里选特种兵，非要从一个新兵开始训练特

种兵一样，怎么能不事倍功半呢？”

“CMMI 和敏捷配合才是最经济的做法；而那种想把整个公司都变成敏捷团队的想法，

和把整个师，整个军训练成特种兵一样不切实际。”

„„

我们俩你一句我一句，越说越兴奋„„，只可惜，如果真能这样，一场大闹天宫的好戏

恐怕就看不到了。

理论体系

实践 健康 创新 家园

【编按】Frank （ITPUB 金融行业版版主 hz_wm）

《再闹天宫》刚到手时，我十分惊讶，原来专业枯燥的学术文章，也可以这样精彩！

恺墨另辟蹊径，从一个引人入胜的话题，拓展到 CMMI 和 Scrum(敏捷)之争。一个是传

统的项目管理领域阵地，一个是渐渐引发高潮的方法论，两者之间必然有联系，有争论，有

交集。

争议是永恒的现象。每一个新生事物，总会带来各方争议，引发传统和现代的思想文化

冲突；争议也会带来进步，只要是有理、有据、有节的争论，会给双方带来完善和发展的机

会。

原本我和恺墨交流的结果，都感觉本期主题敏捷话题太多，不小心间已经成为敏捷专刊，

重点过为突出。本着百家争鸣的态度，需要与业内各位项目管理专家共同商榷，打造电子杂

志的交流沟通平台，以一种负责任的精神推进杂志的发行。

作为一位资深从业者，我对敏捷本着“不跟风，不抵制”的态度，去接触和实践新的方

法论的。我与恺墨的交流是愉快的，而且我也为他深厚的功底所折服，我们的观点也基本一

致。

本文给大家提出了一个课题：无论是传统理论，还是现代思想，必然都需要经过实践的

检验，每一个新生事物都是需要落地的，传统需要不断得到创新发展，新生事物也会存在不

完善的地方，有争论才会有发展。

“百花齐放，百家争鸣”象征不同学派的涌现及各流派争芳斗艳的局面，CMMI 也好，

敏捷也罢，正是项目管理领域空前繁荣的一种体现。PMBar 电子杂志的创刊，我们都认为是

“一切从实践中来，回实践中去”的典型。无论多么新奇的事物，如果不能有效落地，终归

是纸上谈兵，无论曾经多么辉煌的方法论，如果没有在继承中发展，则很可能无法长久。

PMBar 动态

实践 健康 创新 家园

PMBar 动态

中关村大厦宣讲活动

2011 年 10 月 23 日下午 15 时 30 分在中关村

图书大厦五层多功能厅，电子出版社博文视点与

中关村图书大厦联合举行了 IT 项目管理主题活动。

《IT 项目管理那些事儿》主编王保强老师、副主

编冯国馨老师和项目管理资深专家刘羚老师分别

结合该书，从 IT 项目管理的三个方向为大家作了

精彩分享。

活动由 PMBAR 社区创始人兼《IT 项目管理那

些事儿》副主编冯国馨老师主持，博文视点张月

萍编辑出席现场。

《IT 项目管理那些事儿》主编王保强老师结合自己的项目管理实践，从国内项目管理现

状、项目管理成功要素、项目干系人管理、项目

成本管理、项目范围管理等多方位进行了经验的

分享。其中，着重对项目管理成功要素、项目干

系人管理两个方面结合自己的亲身经历进行了

细致的讲解。 “关键干系人”，“政治”等词汇

反映出这次分享的鲜明特点：务实。而“简而言

之，项目经理只有义务而缺乏权力。”则道出了

大部分项目经理的苦衷。分享中，王老师给这些

项目经理支了不少“怪”招。

“PMO 的生存与发展”，刘羚老师层层揭开

PMO 神秘的面纱，与大家共同探讨了 PMO 定位、PMO 职责等几大方面的问题。特别是对

2010 年 6 月，第九届中国系统与软件过程改进年会(CSSPI2010) 北京主会场举行的“PMO-

生存还是毁灭?”PK 大赛各方观点的讲评，吸引

了全场的目光， “PMO 就是为项目服务的，体

现的是项目管理能力，过去企业中有一些机构，

如调度办、管理办、计划办等等，在各个项目之

间进行协调，那么，作为项目总调度的 PMO 就

应运而生，而如果项目管理做得很好了，也许

PMO 就该应时而变，可以撤销了。”一席话很实

在，也很到位。

第三位主讲人是冯国馨老师，重点对项目团

队建设进行了精彩的分享：探讨了项目团队建设

和企业文化的关系，并通过具体的事例从组织级、项目级、人员级三个层次分别阐述了团队

建设的要点；还分享了项目管理中简单有效的绩效考核方法。而最后引用苏格拉底的名言“自

然赋予我们人类一张嘴，两只耳朵。也就是让我们多听少说。” 则点出了作好沟通的关键，

PMBar 动态

实践 健康 创新 家园

可以说是画龙点睛。

近两个小时的分享，大家听得意犹未尽，收获颇丰。很多发生在身边的事，若是跟着专

家的思路，换一个角度去思考，却体验到一种柳暗花明的感觉。我们期待着将来有机会聆听

三位专家更多的分享。（记者／ 恺墨）

本次讲座内容的链接是 http://www.pmbar.net/read.php?tid=1022

嘉宾介绍：

王保强：12 年 IT 工作经验，曾在多家国内外知名 IT 企业任职。ITPUB 数据仓库和 SQL Server

版块版主。《剑破冰山—Oracle 开发艺术》一书合著者。关注领域包括证券、航空、游戏、

电信等。在数据库开发和优化、数据仓库、系统架构、大中型项目管理、Web2.0 方面有很

深的造诣。

刘羚：从业 20 多年，专注 IT 项目管理。曾在神州数码、赛迪、国家信息化测评中心等企业

历任质量经理、咨询顾问、绩效与项目管理总监等职，过程管理、管理咨询、企业级项目管

理、绩效管理资深专家。

冯国馨：联合永道副总兼 CTO、创业合伙人；www.pmbar.net 项目研发管理实践社区创始人。

美国 PMI 协会 PMP 会员、中国系统与软件过程改进协会主任专家会员、中国计算机学会软

件工程师工作委员会委员、北京市商务局 CMMI 认证基金验收组组长、CSDN CTO 俱乐部项

目与研发管理专委会会长、IT168 项目管理超级版主等。

PMBar 系统和软件度量沙龙活动报道

记者／吴越

2011 年 11 月 8 日下午 14:00 在中国互联网络信息中心 215 会议室，PMBar 与 CSPIN

联合举办了系统和软件度量沙龙活动。本次活动得到了大家的高度关注，现场座无虚席。业

界资深专家：中国银行软件中心资深项目经理冯军鸿先生和暴风影音 CTO 杨立东先生分别

做了精彩的主题演讲。

冯军鸿的演讲题目是《从无到有建立

度量分析体系实践 》，他介绍了如何建立企

业度量体系、过程能力基线库，如何应用

GQM 方法，并结合实际案例详细讲解了如

何结合历史数据对规模、工作量、进度、

成本、质量进行估算。最后介绍了项目计

划沙盘演练器、项目估算简易计算器、度

量分析常用工具等内容。

PMBar 动态

实践 健康 创新 家园

杨立东做了《行业服务 VS 互联网公司度量

实践》主题演讲，从度量需求的来源开始介绍如

何从 PMO、管理者角度确定度量的内容，从行

业服务角度介绍如何结合客户和老板的想法来

确定度量指标，从互联网行业特点详细分析了度

量实施的步骤和重要注意事项，最后介绍了度量

实践的差异和共性。

参加会议的人员积极与两位专家互动，提出

了很多实际问题。比如大家普遍疑惑的关于度量

和考核之间到底是什么关系？能否用度量指标进行考核？CMMI 度量与敏捷度量之间是什

么关系？有多少企业在有效应用度量？度量在企业中的实际应用到底达到了什么效果？两

位专家结合自己的公司情况分别做了非常详细的解答。

关于度量方面的方法、理论和书籍在国内其实已经比较多了，但本次沙龙活动突出的是

在企业具体实施的时候如何应对复杂的环境，如果找出适合自己的度量目标、指标，如何让

度量量体裁衣、以最少的成本获得最大的效果。因此大家都觉得收获颇丰，意犹未尽。希望

以后能有更多的企业给大家进行分享，能有更多的机会得到专家的指点。

本次沙龙活动内容的链接是 http://www.pmbar.net/read.php?tid=1155

嘉宾介绍：

冯军鸿

中国银行软件中心资深项目经理，国内优秀的软件企业 CMMI/GJB5000 提升专家、实

战派项目管理/质量管理咨询培训专家。长期专注于 CMMI/GJB5000、项目管理、质量管理、

核心团队建设等领域的研究。服务过多家大型软件企业，领导软件项目资金过亿。凭借十多

年项目管理、监管经历，以及丰富的咨询培训经验，帮助众多企业提升组织与个人绩效。带

领多个项目通过 CMMI 评估。

杨立东

暴风影音 CTO，PMP，PMBar 项目管理实践社区资深专家。毕业于北京科技大学，获

得加州州立大学富尔顿分校（CSU, Fullerton）计算机硕士学位。现就读于中欧国际工商学

院 EMBA 专业。11 年的软件行业从业经验，8 年以上的软件架构设计经验，在加入暴风影

音前，曾经在多个知名 IT 企业任副总裁和首席技术官。

PMBar 动态

实践 健康 创新 家园

IT 项目管理那些事儿－书评

采编／Frank

百度空间网友分享：

hitbird 的分享

在网上订购了《IT 项目管理那些事儿》这本书。

一口气读完，谈谈感受：

很专业，也很实际，记载着 IT 人的喜怒哀乐。

但是也什么都没有。

《IT 项目管理那些事儿》书是好书，正是我所需要的。往往言之有物的书，我感觉还没有用

处。

生活，就像一杯酒，需要每个人去品味。

那么项目管理，以及这本书，我想也是。

亚马逊 amazon.cn 书评：

平均 5.0 星 内容挺不错的！, 2011 年 9 月 18 日

李宗鹏 - 查看此用户发表的评论

收到书，先大体浏览了一遍，里面描述的挺好的，以真实案例的方式体现项目的管理，比较

容易接受和学习！ 力挺

bird - 查看此用户发表的评论

终于看完了。

这本书是好多作者写的项目管理故事。对我来说，头几章和最后几章的内容非常实用。中间

几章是讲组织级项目管理的，不是很懂。其他部分都很有借鉴价值。

ZYP - 查看此用户发表的评论

书很快就到了。感觉挺不错，就是纸质可能有点不太理想，不过关系不大。希望读完后对我

以后的管理知识有大的提升。

China-pub 网上书店 书评：

superstone 发表于：2011-9-23 12:55:00

其中的一位作者送了一本给我，前 2 章看完了，说说感受，第一章是@不胜人生一场醉 PMBAR

写的，行文生活化，手法偏技术，如果我来写，估计出来的风格很类似，第二章@蔡晓东_ ，

这一章可以作为电信行业项目管理的实战手册，文章脉路很清晰。整个项目过程涉及的节点

都有作者本身深刻的理解很具参考价值。

caixda 发表于：2011-8-28 19:32:00

这系统……删除了重新评分也不行？看完了，感觉不错。各作者从自己的角度，用案例来说

PMBar 动态

实践 健康 创新 家园

理。能够再多一些案例就更好了。

拿到书了，感觉不错。国内的 IT 项目管理书籍多以理论为主，很少有这样以实践案例展开

的。看了几章，感觉案例还是能够启发思考的。

当当网评论：

开心大狗 2011-09-14 13:43:39

内容已经大概齐过了一遍，挺丰富的，包括了项目经理个人级管理、过程级管理、组织级管

理的东东，在实际工作中能借鉴到不少好经验，期待一下本更好的。现在项目管理的模型和

理论很多，比如敏捷，scrum、cmmi 啥的，真正有帮助的还不是很多。很高兴能看到这么一

本能在项目管理工作中提供借鉴的书，要是能有个完成的项目管理案例介绍的书就更好了，

wangonly75@***.*** 2011-09-13 11:47:50

非常喜欢本书！看得出本书的创作团队在 IT 行业摸爬滚打多年，是多年实践经验的总结。

特别地，对于新入行的朋友们来讲，非常有参照价值。作者们通过勇敢的实践剖析，让我们

看到一个个鲜活的项目管理过程。除了阅读的快感，结合自身经历的探讨和实践，形成的共

鸣让我更受益。先买 5 本，送给身边的 IT 经理人。

Leo 飞 2011-09-13 10:59:46

买来好几天了，简单说一下：

目录的结构很有特色，一眼便可以看出是出自于不同作者的手笔，每个作者个性鲜明，在目

录安排上独具匠心。

粗浅得将书翻阅了一遍，有几篇文章可能和我工作比较有关联，因此对这几篇文章印象特别

深刻。这几篇文章基本能将一个项目中遇?的所有问题都穷举了出来，也有现象配合的解决

方法，比较适合正在做项目管理的人进行借鉴。

还有几篇文章是讲述项目管理体系和具体 CMMI 等内容的，写得也是非常精彩，很适合在大

型项目管理中进行运用。

Thomas150 2011-08-30 16:18:34

看了头几章，很不错。作者是真正做过 IT 项目的人，他们的实践对我们这些 IT 项目经理有

启发。组织篇还没有顾得上细看，粗粗浏览过去，感觉也很好。

360buy 京东商城：

xiaoban0514

当小说看蛮有意思的 2011-10-31 10:49

写的还不错，最后一章不是很喜欢，用那么多古文的引用，有点杂乱。其他章节着实写的不

错。

狂者自颠

值得一读的书 2011-10-28 11:22

作者都是活跃在项目管理方面探索的人士，在微博上也能关注到他们，通过此书相互交流中

国 IT 项目管理中的所见所想，值得在中国 IT 领域中摸爬滚打的项目经理们读一读，语言平

实易懂，算是一本还不错的书。

PMBar 动态

实践 健康 创新 家园

xianran5

有不错的实际帮助 2011-10-27 20:41

第一次读作者如此之多的书籍，涉及行业较多，多实践经验为基础，可操作性强。（读过类

似标题的书：Java 程序员那点事，比这一本写得好）

gabriel1

无奈的一本书 2011-10-13 17:04

读过之后，觉得没有什么收获，就像读了本二流小说，购买者请慎重！

sunilike

还不错，可看 2011-10-10 09:00

看了几页，具体可参照性实用，就是没有传文化的根基不要硬扯

不烦恼阿

都是经验 2011-09-25 21:36

其实每一章都可以写成一本书，对项目经理具有很好的借鉴意义，经验这东西能够给分享就

是好的（不管是为了谋求利益还是其他的想法），不能分享的人永远达不到事业的最高境界！

PM 人物

实践 健康 创新 家园

PM 人物

记者／记忆

陈勇老师您好，久仰大名，对您的经历和研究方向深表敬佩。

您先自我介绍一下？分享一下您的职业经历？您从事过的工

作？

我从 95 年毕业以来，一直从事软件相关的工作，大致可以分

为三个阶段：

95年～03年主要担任程序员、项目经理等角色，任职于合众

思壮、清华同方等企业，参加了一些国庆阅兵、CCTV数字电

视等项目，积累了一些软件开发过程的一线知识。

03年～07年则主要担任内部的过程改进人员及外部的职业咨

询师，任职于普天、亚信等研发企业，以及 SoftTech、DNV

等咨询机构；初期的咨询内容是项目管理、CMMI、功能点估

算等，后期则偏向敏捷开发。

08～11 年则担任某外企中国部门的咨询总监、事业部总监、

副总经理等职位，负责咨询、销售、市场和一部分产品工作；

这个阶段深入接触了很多国内的顶级企业，如腾讯、金山、

盛大、汉王、金蝶等，由于他们采购我们企业的敏捷开发管

理工具，因此在接触的深度上超过以往的咨询。

经历好丰富，真让人羡慕。那您工作这么多年来，个人最为

满意的工作成果是什么呢？

上面的研发过程整体上看起来挺“曲折”的，不像是一条纯

正的走“敏捷开发咨询”的道路，但是这些曲折现在回头看

来，对形成自己独到的敏捷开发见解，并对敏捷开发的具体

实践加以改进奠定了很好的基础。从这个角度看，最为满意

的工作成果是对传统敏捷开发的突破，包括将传统团队打造

为特性团队（Feature Team）的“松结对编程”、对“自组

织团队”的深层机制做出解释的敏捷生态系统、以商业目标

为驱动的长周期版本策略等独到内容。

PM 人物

实践 健康 创新 家园

那你是如何从研发的道路上走到“敏捷开发咨询”这条路上

来的呢？中间也经历了很多曲折的过程吧？

前期漫长的软件开发过程积累了丰富的一线经验，因此在使用或

培训敏捷开发的时候不会照本宣科地生搬硬套，而是会结合实际

企业的情况，进行裁剪和变形，以便适应团队、文化、人员方面

的约束。比如由于结对编程在国内很难应用成功，我们在实践中

采用了另外一种较为松散的“师徒制度”进行代替，其中包括了

共同设计、简化估算、技术指导、代码审查等一系列实践，也就

是后来被命名为“松结对编程”的微观团队结构。

中间的 CMMI、功能点咨询经历，则形成了系统化思维的习惯。

敏捷开发是一种来自于实践、比较原汁原味的方法，因此若使用

得当会非常实用；但若要推广的环境与实践产生的环境差异很

大，则适得其反，国内的很多企业推广敏捷受阻都归因于此；而

此前的 CMMI、功能点分析等方法则在从实践产生后进行了相当

大的提炼和系统化，因而也要求在使用时有一个“落地”的过

程，不能生硬地使用。这一系统化的思维方式，对日后在不同企

业如何推广“敏捷之神”而非“敏捷之形”，即“不同企业的敏

捷落地问题”打下了基础。

最后的一段市场、产品、销售结合的职业生涯，则从更高的角度

理解敏捷开发的整体环境。比如敏捷开发一般实践都是关于项目

管理、需求开发、测试技术等方面，这些内容均来自于早期敏捷

实践者的实际一线工作，具有极强的实用性和操作性；但也同样

因为受限于其视角，造成敏捷开发如何与商业目标结合、如何与

客户达成交易（而不是简单地沟通需求）、如何进行大团队管理、

如何进行绩效考核等企业关心的内容的缺失。由于我们所销售的

工具不仅限于敏捷开发的内容，而且实施周期也可能长达几个

月，这就使得自己养成了不能简单地做完敏捷培训就走，而是要

将敏捷开发的活动落实、嵌入到企业的正常运行过程中。1-3-9

团队模型、敏捷绩效管理、敏捷产品版本管理等内容均是在这一

阶段形成的。

真是非常宝贵的经验，我想，您的这些经验之谈，会让很多

人事半功倍的！非常感谢您的无私分享。刚才您说了很多以

前的工作经验，现在我们迫切地想知道您当前主要的工作是

做那些事情呢？还是在敏捷的领域吗？您未来的工作方向会

是什么呢？

PM 人物

实践 健康 创新 家园

当前的主要工作方向，是在咨询、培训之余，带领一个软件

团队编制中国的免费敏捷开发工具。

最早有这个想法，是在每次培训之后，现场学员都希望推荐

一两个工具或模板进行实际开发使用。后来在课堂练习的时

候，就留下了几个 Excel表格。但尽管 Excel表格中采用了

一些归纳、筛选的技术，毕竟商业软件的开发需要大量的人

工，也会产生大量的用户故事，完全不是一张表格所能进行

管理的。

这个工具暂名“火星人”，其未来方向是打造以产品管理为

核心的敏捷开发管理，而不是像传统的敏捷开发工具一样以

看板为核心，从而成为高层领导-产品经理-开发团队的桥梁。

“火星人”？就是您现在的网名吧？我们对这个工具真是充

满期待。这个工具必定会给中国敏捷领域带来翻天覆地的变

化。那您在敏捷开发领域最深刻的感受是什么呢？对敏捷开

发未来怎么看待呢？

我认为当前敏捷开发正在经历一个“打散重组”的过程，其路

径有点像又不完全像 CMMI的情况。

敏捷开发在刚刚开始出现的时候是很“灵活”很“革命”的，

几乎没有成体系的开发过程标准。之后才逐渐出现了 XP和

Scrum两个分支。XP出现后不久，就走上了“打散重组”的道

路，即不再整体宣传和实施 XP，而是截取其中最有效果的部分

如用户故事、持续集成、自动化测试等实践；其他较为难以实

施的部分如现场客户、结对编程则不再坚持。Scrum则一直走

在非常类似 CMMI的模型化的道路上，这一方面利于学习和初期

实施，另一方面则不利于灵活应用，容易出现封闭性。在产品

优先级排序、迭代开发、计划会、评审会等实践较为成功的同

时，每日立会、反思会、Scrum Master等实践则陷入困境，

日后也必定会走上“打散重组”的道路。

在打散重组的同时，也会重新引发一个根源问题：“到底什么

是敏捷？”这并不只是一个停留在字面上的哲学问题，而是将

可能对未来软件工程发展带来深刻影响的实质性问题。国内软

件工程经历了混沌开发、瀑布式开发、CMMI、敏捷开发这几个

思想阶段，“到底什么是敏捷”的问题，实质上是“应基于什

么来定义和推广研发方法”的问题，处理得当会对未来的研发

管理方法的进化产生深远影响。

PM 人物

实践 健康 创新 家园

相信未来敏捷开发领域将会在您的倡导下，走向更加成熟。

从哲学走向实际，不断改善，不断完善，真正发挥“敏捷”

的实际作用。在最后，您有什么要对 PMBar 和我们电子杂志

说的吗？

在敏捷开发脱离生硬的“敏捷”二字而被打散重组的时候，敏

捷开发才成为真正意义上的敏捷开发。回归后的敏捷将会以需

求管理、项目管理、质量管理这些开放分类重新组织其知识结

构。这时候 PMBar这类开放组织将具有很重要的地位。

因为 PMBar不是 CMMIBar，也不是 AgileBar，而是不拘泥于具

体开发方法的项目管理组织（实际上也涉及需求管理、质量管

理等领域），这样才更容易兼容并蓄地对待所有开发方法，不

会激进，也不会过时，最终才能追寻真正的敏捷开发方法前进。

非常感谢陈勇老师接受我们的采访，并分享了这么多的经验，

相信在很多读者读过这篇采访稿后，也会不禁拍案叫绝。也

希望陈勇老师未来能够再次和我们分享经验。谢谢！再见！

感谢大家的支持。再见！

PM 人物

实践 健康 创新 家园

记者／记忆

接下来要向大家推荐一个了不起的人物：王立杰，"速

评网联合创始人兼 CTO"，在管理方面有着非常丰富的

经验，王总，您先来做个自我介绍吧！分享一下您一

直以来的职业和您一直在关注和从事的工作？

我 2002年从北邮硕士毕业后，先后在 Bell Labs、Agilent 等外

企做了 8年多的软件研发与项目管理，于 2010年受邀加入 DNV做

了一段时间的敏捷咨询师，目前联合创建了“速评网”。先后给

一些企业做过敏捷开发方面的内训或指导，譬如阿朗、Ericssion、

Nokia、Vmware、E人 E本、信城通等。业余时间，我会参与或组

织一些敏捷社区活动或行业会议，譬如“CSSPI过程改进年会”、

“Scrum Gathering”、“Agile China敏捷中国大会”、

“Agile Tour敏捷全球之旅”、“西安 Web开发者大会”、“IBM

全球开发者大会”、“MSUP亚太软件研发管理峰会”等，有时也

会在《程序员》杂志上发表一些敏捷相关的文章。作为敏捷的实

践者及推动者，通过总结自己带领敏捷团队的经验，以及跟实施

敏捷的公司及社区的接触，总结出了一套敏捷最佳实践，于 2009

年 6月合作出版了国内第一本小说体敏捷著作 ------《敏捷无

敌》，期望以一种轻松的方式讲述敏捷，让读者在获得知识的同

时，拥有阅读的快感。

敏捷的实践者及推动者？现在敏捷这个话题很火，您

现在敏捷方面正在做些什么呢？

为了解敏捷在中国的实施状况，我正发起“敏捷中国实施状况调

查”，网址是 http://incredibleAgile.com/survey. 期望正

在实施敏捷的童鞋们，积极参与。因为填写调查的过程，不仅是

一次自我总结、自我提炼的过程，而且也是一次自我学习、了解

业界最新发展状况的过程。

您在敏捷方面有这么多的贡献，都是之前我们大家所

不知道的，太感谢您了。那您现在主要的工作是什么

呢？您对未来工作的规划是怎么样的呢？

PM 人物

实践 健康 创新 家园

“速评网”(www.361test.com)是我们今年刚上线的一个云计算

产品，我们正致力于用敏捷方法为企业客户提供简历筛选、招聘

测评、面试管理的一站式招聘解决方案，我们的目标是使企业招

聘测评时间节省 80%，测评准确性提高 100%，招聘效率提高 100%。

对于未来，我会在做好这份事业的同时，积极投身到敏捷在中国

的推广活动中，通过培训、宣讲、组织社区活动等形式给大家带

来更多的分享，期望跟大家一起成长。

速评网是一个值得我们关注的产品，而您在敏捷的推

广活动我们也会随时关注的。那您在工作这么多年

来，肯定有很多关注的东西，现在我们知道了，您最

关注“敏捷”这个领域，那您在这么多年工作中个人

最满意的工作成果是什么呢？

我在 Agilent 曾经带过一个敏捷团队，这个团队的凝聚力、战斗

力非常强，整个团队发生了非常好的化学反应，团队的生产力很

高。正是因为敏捷的成功实施，在 2009年获得 Agilent内部

“NSD Merit Award”，我们是当年获此殊荣的唯一中国团队。

对您的仰慕之情犹如滔滔江水之延绵不绝。现在很多

人对敏捷都只了解到皮毛，每个人对敏捷也都有不同

的认识，您以这么多年的经验，说说您对当前敏捷开

发的最深刻的感受，敏捷的未来会是怎么样的呢？

一种理论的成熟一般需要 20年左右的时间，敏捷作为一个新的研

发体系与方法，到今年差不多有 20 年了；而今年刚好也是《敏捷

宣言》发表后的第 10个年头，理论的成熟与先期实施者的示范作

用，使得敏捷已经越来越受到国内众多软件研发企业的重视，这

种应用热潮正以很快的速度从外企向国企、民企扩展。由于受到

前所未有的追捧，相信在未来的 5年内会有超过 80%的企业逐步采

用或尝试敏捷。作为从业者，越是在这种时候，我们越是要保持

清醒的头脑，要有选择、有步骤的去实施、去尝试，毕竟敏捷也

不是“银弹”，不能解决所有的问题，我们应该把敏捷当做一种

持续改进的积极态度！

PM 人物

实践 健康 创新 家园

最后一个问题了，请您简单谈一下您对 PMBar和电子

杂志的寄语！

作为 PMBar 社区的一员，非常欣喜的看到我们突破了线上论坛、

MSN群在线讨论和线下地面沙龙的交流形式，又找到了新的交流媒

质。愿 PMBar以此电子杂志为契机，不断的创新、拓展，凝聚社

区的力量，为广大 IT从业人员打造一个分享、沟通、探讨的有机

平台，从而提高中国 IT项目管理的整体水平。最后，预祝我们的

电子杂志越办越好，最终能够成功发行纸质版。

感谢王总，也期待王总祝愿能够早日成真。再见！

感谢各位的支持！再见！

开心一刻

实践 健康 创新 家园

轻松一刻

蓝精灵歌大家唱

采编/记忆

《蓝精灵》这部曾经带给 70 后 80 后快乐童年动画片的主题曲歌词引发集体怀旧热潮，

更多网友找到了一个最大的潜力点：蓝精灵主题曲。通过改编歌词，出现了“蓝精灵体”，

以至于被各行各业的网友们改编成了吐槽专用体。

对于这样的社会热点，我们 PMBAR 也当然在持续关注中，连续一个月，在 PMBAR 的

论坛、MSN 群和 QQ 群里，不断出现了这些有着我们自身行业特点的“蓝精灵体”作品：

【会计版】：在那山的这边海的那边，有一群小会计，他们可爱又聪明，他们每天输凭

证，他们没日没夜迷失在那，无垠的账表里，他们沉着冷静相互都支撑。噢，可爱的

小会计，噢，可爱的小会计，他们结账编表加班不加薪。

【审计员版】：在火车的那头飞机的那端，有一群审计员，他们都是大白痴，他们每天粘数

字，他们每日每夜没有周末迷失在那底稿里，他们沉着冷静地调整 1 分钱。噢，非人的审计

员，哦，非人的审计员，他们齐心协力完成了项目却又木提成，还变成了剩男和剩女

【程序员版】：在那山的这边海的那边有一群程序员，他们老实又腼腆，他们聪明但

没钱。他们一天到晚坐在那里熬夜写软件，如果饿了就咬一口方便面！哦苦命的程序

员，哦苦命的程序员，只要一改需求他们就要重新搞一遍，但是期限只剩下最后两天。

【设计师版】：在那格子间的图纸堆里，有一群设计师，他们光鲜又靓丽，他们拼命又努力，

他们呕心沥血不分昼夜都在赶图纸，他们年复一年盼着涨工资。噢苦命的设计师，噢苦命的

设计师，他们齐心协力开动脑筋想出个新方案，隔天老板要求重新做一次。

【数据分析师版】：在那山的那边海的那边，有一群数据分析师，他们辛苦又聪明，他们每

天看数据，他们呕心沥血不分昼夜都在赶报告，他们年复一年盼着涨工资。噢苦命的数据分

析师，噢苦命的数据分析师，他们齐心协力开动脑筋找出数据背后的规律，他们的分析结果

还是不被重视。

【项目经理篇】：在那办公室的角落，会议室里，有一群项目经理。 他们天天开米听（meeting），

他们经常吃批评。 他们号称经理，手下没兵，统统自己打理，一天到晚忙到筋疲力尽。 噢，

可怜的项目经理，哦，作孽的项目经理。 不管需求不清，预算太低，供应商太傻逼，老板

最终只骂项目经理。

【项目经理篇——恺墨编】：在那山的南边海的北边有一群 ITer，他们苦苦地寻觅，他们努

力的钻研。他们一天到晚找寻传说中的阿拉丁神灯，他们辛勤劳苦就是为了项目的成功！哦！

伟大的 ITer，哦，团聚在 PMBar，他们费尽心力一心只为中小企业的项目管理，让我们都关

注@IT 项目管理那些事儿。

开心一刻

实践 健康 创新 家园

从 0 开始认识塔罗

文/记忆

罗牌，是一直以来的流行语，不“星座”、“预测”、“占星”拥有着同样的地

位，塔罗牌也是最为古老的学说乊一，现在，它已经成为人们日帯生活中十

分熟悉的东西，已经成为西斱社会人们生活丌可戒缺的一部分。塔罗中蕴吨

了深邃的哲学奥义、神秘的精神丐界、丰富的人生智慧和优美的艺术内涵，在丐界各地有非

帯多的机构在对塔罗迚行多斱面的研究。随着时代的发展，今天，塔罗的大众性不娱乐性也

日益加强，逐渐成为了丐界各国人民喜闻乐见的牌类预测游戏及艺术藏品。下面，就从塔罗

最基本的尝试向大家介绍：

“塔罗”一词，Tarot，是取自埃及语的 tar(道）和 ro(王）两词，吨有“王道”的意

思。因此，“塔罗”本身即喻挃王者应该具备的超越帯人的决断力。相传，“塔罗”原是一本

“叨忒乊书”，叨忒，埃及月神，乃文化教育乊神。这本书是用来传达天神旨意的神秘乊书。

当古代埃及法老遇到疑难问题的时候，就会打开这本“叨忒乊书”，随后，所有的问题便能

迎刃而解。后来，埃及灭亜，为了丌让异族得到此书，于是将书中内容绘制成卡片，亝于神

官手中。卡片被流传了下来，后来传到欤洲，在中丐纪形成了如今我们所熟知的——塔罗

牌。塔罗牌是智者将古老的智慧宝典绘成的图案，它是神秘不智慧的结晶。

作为预测工具，塔罗牌主要运用象征的图像，辅以占星学、卡巳拉数字学、色彩学等来

解答问题。传统的一副塔罗牌由 78 张牌组成，

其中 22 张主牌，称作大阿卡纳，另外有 56 副

牌，称作小阿卡纳。每一张牌都有图案和对应

的名称，这些名称揭示了生命的奥义。塔罗预

测，就是使用这 78 张牌摆放成丌同的牌阵，从

中解读塔罗给予的预言不启示。

塔罗牌里的大阿卡纳第一张被称作愚人

（The Fool）。这张牌的形象是一个穹着色彩斑

斓的衣服，戴着像小丑一样的帰子，手舞足蹈，

昂首阔步，站立在悬崖边的人。他是鲁莽而无

知的：他的右手拿着象征权利的权杖，挂的包

袱里装着经验，而他只是漫丌经心地扛着，却

丌懂得如何运用。他头上的桂冠代表着成功的

可能。他拥有着一颗相信梦想和纯真的心；他

塔

开心一刻

实践 健康 创新 家园

左手拿着白玫瑰，白色象征纯洁，玫瑰象征热情，脚边的小白狗象征着愚人和动物一样，凭

本能行事。他无畏于脚边的悬崖，眼望长穸，神色欢欣。进斱的山脉象征他未来的旅程。他

永进沐浴在白色的阳光下。在韦特塔罗中说过：愚人是追寻经验的灵魂。

在希腊神话中，众神乊父宙斯不忒拜国王卡德摩斯女儿塞墨勒的私生子，酒神法狄俄尼

索斯，他长大后，到丐界各地流浪，历尽考验，在流浪途中，他掌握了有关自然的所有秘密

以及酒的历史。凡他所到乊处，便教人如何种植葡萄和酿出甜美的葡萄酒。据说他就这样漫

游，从希腊到小亚细亚，他敢于冒险，甚至进到印度和埃塞俄比亚。他走到哪儿，乐声、歌

声、狂饮就跟到哪儿。他不愚人牌的牌义相对应，同样是无所畏惧的、充满希望的精神，是

无拘无束的自由的人。

愚者这张牌，是塔罗牌的第一张，也是起点，它代表着 “0”，表示什么都没有，就好

像一无所有，一无所知。另外，它还代表了：一个新开始，迚入一个新阶段，产生一条新路

徂，范围有了新的边界，开始做一件新事情，开始去旅行，迚入一个位置的领域……；同时，

它还象征着信仰，开放的心态，困惑不恐惧，快乐的生活和无忧无虑的思想。它的关键字就

包括了：开始、自由、天真、流浪、大胆勇敢、旅行、信仰、自发、愚蠢和希望。

在塔罗牌中，正位牌不逆位牌的解读是丌同的，对于这张愚人牌，逆位的意思不正位，

丌完全是相反的，而是一种互补的关系：

正位释义：

憧憬自然的地斱、毫无目的地前行、喜欢尝试挑戓新鲜事物、四处流浪。

明知是毫无意义的冒险，错误的选择及失败的结果，却一意孤行，盲目地追求梦想而完

全忽略现实；好冒险、寻梦人、丌拘泥于传统的观念、自由奔放、一切从基础出发、四

处流浪。

自由恋爱、丌顾及他人看法、以独特的斱式获得成功、轻易坠入爱河、浪漫多彩的爱情、

独特的恋人、等徃亝往机会。

工作上具冒险心、追求新奇。

热衷于事业戒学业、以独特的斱式取得意外的收获、由于好奇心对当前的学业产生浓厚

的兴趣、把握重点、寻求捷徂、倾向于自由的工作氛围、适合艺术类工作戒从事自由职

业。

健康状冴佳。旅行有意外收获。

美好的梦想。

１．愚蠢而无知，毫无经验，盲目行动。

２．狂乱的精神状态，极度兴奋，毫无知觉。

３．象征旅行的开始，有追求新奇的冒险乊心。

４．从零开始，走成完满的囿，包吨无限可能，潜力无穷。

开心一刻

实践 健康 创新 家园

５．搬家，转学等等，迚入一个全新的环境。

６．丌拘形式的自由式恋爱。

７．异帯于别人，有艺术家的气息。

逆位释义：

冒险的行动，追求可能性，重视梦想，无视物质的损失，离开家园，过于信赖别人，为

出外旅行而烦恼。

心情穸虚、轻率的恋情、无法长久持续的融洽感、丌安的爱情的旅程、对婚姻感到束缚、

彼此忽况忽热、丌顾众人反对坠入爱河、为恋人的负心所伤、感情丌与一。

工作缺乏稳定性、无责任。

成绩一落千丈、没有耐心、行事缺乏计划、经帯迟到、猜题错误导致考试失利、考前空

击无法为你带来太大的效果。

因丌安定的生活而生病。

丌能放心的旅行。

丌能下决心、怪癖。

丌切实际。

１．比正位的愚人更加漂泊，鲁莽，疯狂。

２．代表缺席，戒由于过度小心而错失良机。

３．缺乏感情，戒感情轻浮。

４．缺乏责任心，没计划，走错路。

５．灵魂堕落，失去纯真。

如何来理解这张愚人牌呢？愚人，就像我们现在一样，我们乐观面对一切，相信自己的

感觉。可能我现在没有一个确切的目标，但是我可以想到哪儿就做到哪儿。别人眼里的丐界，

是径复杂的，丌仅黑暗、多变，而丏也充满了诱惑和堕落。但是，对于这种充满市井风气的

多元穸间在我看来，事情想怎么办就怎么办，中间的一些空发事件，我丌会畏惧，在遇到困

难的时候我总有办法去应付！把事情单纯地做就好，无知其实也是一种享受。

愚人的代表数字是“0”，丌仅象征着一无所有，也象征着希望无限，潜能无限。愚人

的流浪汉形象，戒许看起来有些准备丌足，可他却自信满满，踏着阳光开始了他追寻梦想的

人生乊旅。也许他的行为在别人眼中是冒险和愚蠢的，就好像是小说中的堂吉诃德，然而谁

又敢说自己的心中没有过梦想呢，只是大多数的人缺乏将梦想实现的勇气罢了。追梦的人敢

于踏上神都丌敢走的路，而结果会如何？成功戒者失败，到这个时候，这个结果还重要么？

这就是愚人的意义，旅行丌在于目的地，而是沿途的风景。这个道理我们都懂，可是放

在自己的人生中，却径容易彷徨。我们有时候真该学学愚人的傻大胆，为了心中所想，去努

力拼搏。戒许一无所成，丌过那又怎样呢？人生短短数十载，莫要让自己留下遗憾才是最重

开心一刻

实践 健康 创新 家园

要的。

愚人牌的牌意到底该如何解读呢？

其实愚人并丌难理解，我们可以把他看作是一个初出茅庐的学生，但是外界不他乊前的

学校生活简直就是两重丐界。在这个时候，愚人拥有无不伦比的热情，稀奇古怪的创意，初

生牛犊丌怕虎的冒险精神，以及对于理想的执着追求。同时，他又是个缺乏经验，四处乱撞

的愣头青，有时候会觉得孤独，有时候会觉得彷徨，甚至有时候会误入歧途。于是他需要时

时自省，同时也需要别人的帮助。

总乊，当愚人牌处于正位的时候，更多的是积极向上的信息。鼓劫前迚，继续努力，就

算暂时没有看到成功的影子也丌要气馁，应该跟着自己的感觉去做。在这个时候需要注意的

是积累经验，沉淀经验，更好的利用自己的学识，多去利用周边的环境，用自己的好奇心去

探索周边的失误，始终保持一颗充满勇气的心。

当愚人牌处于逆位的时候，就要多加小心，要仔细想想自己最近行事是否过于无知和莽

撞。特别是面对人生重大转折的时候，愚人逆位往往意味着欲望戓胜了理智，会做出冲动的

选择，而结果往往会让人后悔丌已，还是要三思而后行。如果是算爱情，愚人往往代表着旅

途中恋情，丌过好好享受过程就好了，别太在意结果。如果是学业，那就代表最近实在太丌

用功，收收心思好好看书吧，实现梦想也是需要实力的。整天做白日梦戒者东飘西荡，对于

以后的人生丌会有任何的帮助。

开心一刻

实践 健康 创新 家园

【现场直击】（解说人：LastWinner）

各位观众！各位听众！下午好！这里是中国互联网络信息中心，现在时间是 2011 年 11

月 8 日 14 点整。万众瞩目的系统和软件度量地面沙龙活动就要开始了。本次活动由 SPI China

和 PMBar 项目研发管理社区首次联合主办。

此次沙龙的主题直指当今 IT 项目管理中的一大难点——度量，因此本次活动得到了社

会各界的高度关注。尽管沙龙的时间安排在了工作日，但会场依然在开始前就满座，开场后

还陆陆续续有人赶到——大家一致认为，这次沙龙的举办地点实在是有点“潜伏”的味道。

在无数粉丝的尖叫声中，首先上场的嘉宾是来自中国银行软件中心的资深项目经理，拥

有多年项目管理、监管经历的冯军鸿先生。他为大家分享了如何从无到有建立度量分析体系，

并以历史数据为出发点，从规模估算、工作量估算、进度估算、成本估算、质量估算等角度

为大家讲解如何利用历史数据迈出企业度量体系建立的第一步。冯军鸿先生的主题，带动起

了在场所有粉丝的热情，也带动起了大家提问的积极性，在不断的提问与掌声中，将本次沙

龙活动推向了高潮。

下面，让我们隆重请出第二位嘉宾——暴风影音 CTO，PMP，PMBar 项目管理实践社区

资深专家：杨立东先生，他以自身多年在传统行业和互联网行业工作经历为基础，为大家讲

解传统行业服务与互联网公司的 IT 项目度量的实践与对比，让大家充分体会到了不同行业

用户满意度和老板满意度的不一样直接影响着不同行业的度量标准、方法的选取与度量的实

践。杨立东先生的话题，又引起了无数粉丝的尖叫，大家的热情更加高涨，将本次沙龙活动

推向了一个新的高潮。

现场的互动积极热烈，尤以来自 PMBar 社区的成员最为活跃，他们结合自身实践及在

PMBar 社区线上交流学到的知识，结合自己工作中的疑惑，积极提问，并不断挖掘出更新、

更细致的问题。由于互动过于热烈，担心在年终考评中被度量不合格而下岗的投影仪和麦克

风集体“罢工”了，以致于会场在很长的一段时间内 现场的嘉宾和观众竞相展示河东狮吼

的神功。随着两位老师均对听众的疑问“度量能否作为 KPI 标准”坚定地否定后，投影仪和

麦克风好像放下心来，终于又开始干活了。

今天的度量战役大获全胜，每个人都收获颇丰，让我们一起来清点本次战斗的战利品：

1、 收集数据。大多数企业现在并没有度量需要的基础数据，因而首先应考虑的是先收

集到相关数据，然后再谈剔除不合格数据的问题；

2、 要实践出合适自己企业的度量方法，别人的方法你可以参考，但照搬实在是不建议；

3、 度量并不一定能降低成本，但是可以提高过程透明度和产品质量。在成本可接受的

情况下，这无疑对以用户为中心的企业是一件对企业和用户都双赢的好事

4、 度量不要过度，不要一开始就追求很小误差的度量，这并不现实。没有准确的精确

毫无意义！噢，太到位了！

5、 不同行业的度量指标是有差别的，弄清客户真正想要的，才好确定度量指标

6、 工具很重要，但用什么工具并不重要，只要能满足你的需求，能有效帮你管理度量

数据，即可。非常提倡在不知不觉中搜集数据，这样的数据误差相对会更小，故而

真实性会更高。对啊！管你用刀叉还是筷子，吃到嘴里的才是真的，是吧？朋友们！

作为 IT 项目管理实践第一社区的 PMBar，在沙龙结束后也着实腐败了一把，组织了一

开心一刻

实践 健康 创新 家园

场小型粉丝与明星近距离接触聚会。聚会上大家热情洋溢，交流的氛围赛过了热气腾腾的火

锅，谈论的话题不仅涉及今天的主题——度量，还涉及到整个 PMBar 社区下一步如何做得

更好。

酒过三巡菜过六味，不对，是五味，六味那是地黄丸。PMBar 社区创始人冯国馨总结认

为，IT 项目管理的缺口实际非常大，很多企业的 IT 项目管理水平还停留在十年前的水平，

甚至还不到。PMBar 公益社区集合的各个行业的专家，均有丰富的实践经验和扎实的理论基

础知识，社区完全有能力在项目管理领域闯出一片天空。事实上社区已经出了一本以项目实

践为基础素材的《IT 项目管理那些事儿》，第一期电子杂志也快到嗓子眼了，错了，是快上

线了；快到嗓子眼的是羊肉。当前 PMBar 社区正在身体力行，扎扎实实一步一个脚印在为

全国的 IT 项目管理水平的提高做出伟大的贡献，力为中国项目管理护航到底！

以上是 PMBar 兼职记者 LastWinner 为您带来的报道，欢迎加入 PMBar，与八百名专家

沟通交流 IT 项目管理的方方面面。本次报道到此结束，在此，我想首先感谢 CCTV 和 MTV

能给我这个机会让我在本次报道中担任记者，谢谢主办方 SPI China 和 PMBar，以及支持单

位中国互联网络信息中心，还有我的经纪人——记忆。在项目管理界好多年了，感概的话就

不说了，今天能够报道二位项目管理专家是我一生最大的心愿，没想到这么快就实现了，我

会一如继往的更加努力做我自己，不做违法乱纪的事，不打架，不骂人，在德智体美劳方面

继续发展，当然了，好好学习天天向上也是我不断激励自己的口号，在此呢我还要特别感谢

主办方，谢谢你们能请出来二位专家，我会继续支持你们的，并且会做好宣传工作，OK，

今年我会更加努力，在此也欢迎大家到 PMBar 参与讨论！ 你们的关注就是我努力的动力。

谢谢大家，THANK YOU!

实践 健康 创新 家园

实践 健康 创新 家园