国内IT项目管理第一实践社区PMBar推出项目管理电子杂志试刊第一期：传统与敏捷，你在什么位置？【专业源于实践，分享互助提升！】

3. 卷首语
【卷首语】
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 月
实践 健康 创新 家园

4. 卷首语
联合永道副总兼 CTO、创业合伙人，www.pmbar.net 项目研发管理社区创始人。
长期从事产品研发、项目管理与团队管理工作。2007 年发起定期线上和地面 IT 项目管
理沙龙活动，与用友集团、阿里巴巴集团、盛拓传媒（IT168） 、神州数码等企业开展项目管
理沙龙交流。
美国 PMI 协会 PMP 会员、中国系统与软件过程改进协会主任专家会员、中国计算机学
会软件工程师工作委员会委员、北京市商务局 CMMI 认证基金验收组组长、CSDN CTO 俱乐
部项目与研发管理专委会会长、IT168 项目管理超级版主等。
新浪微薄 ID：冯国馨 PMBar
MSN：yulin.gu@hotmail.com
实践 健康 创新 家园

5. 群思荟萃
【群思荟萃】 传统，敏捷，你在什么位置？
“敏捷”
，在 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 回顾会议，
与其他种种的项目开发模式并没什么实质性变化。然而，有三方面的收获，是大家由心底感
受到的：
实践 健康 创新 家园

6. 群思荟萃
建立了共同的沟通渠道；
敏捷项目管理的词汇不再陌生，甚至变得亲切；
项目的进度透明了，彼此加深了解，也方便沟通。
如果说敏捷，就是解决以上三方面的问题，那就未免太低估了“敏捷”这个词背后的伟
大意义。我们还没有工程实践，没有敏捷估算，没有相互协助，没有准确地解读燃尽图，离
敏捷到底有多远？
二、 旧代码重构——痛苦的决定
年底业务规划会上，一次由程序员主导的呼声响起了——
老黄，暴风影音研发团队负责人，用他并不擅长的演讲，给我们讲解为什么暴风影音需
要重构，当前的产品存在哪些不好解决的缺陷。听到了很多技术细节之后，我越来越感到心
惊，原来老的产品有那么多设计不合理的地方。
但如果重构，我思考的问题有两个：
这个项目的规模有多大？
重构的周期有多长？
跨全公司范围的所有部门进行重构，又不影响正常业务，这么复杂的一个项目能成功吗？
敢在这个最重要的项目上实施敏捷项目管理吗？讨论了很多次，重构在我脑子里也进行了不
知道多少次，最后的决定是：重构，实施敏捷项目管理！
定义项目的目标和 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 的任务拆分感觉不够细，所以
实践 健康 创新 家园

7. 群思荟萃
打回重新分解。什么叫“细”，我定下了一个标准就是：估算工作量需要在 24 人时内完成。
起初，研发负责人老黄给每个人估算了工作量。当我参加计划会议的时候，估算结果早
已出来了，这让我很惊奇。我让敏捷教练把估算好的结果打印了一份，然后去掉老黄的估算
结果让他对着投影再估算一遍，然后让大家验证。结果有一半都和之前的结果不一样，在大
家的哄堂大笑中重新开始了估算。没有专业的敏捷扑克，我们就靠喊，在大家的呐喊声和老
黄的打压声中，每个人的估算结果终于汇总出来了。
五、 需求，一个老话题
历来，需求都是软件项目管理的难题之一。这次为了管理好需求，我们选了公司最好的
产品经理干哥定需求模板。当研发人员都喜欢看，带有标准的建模工具画出的逻辑图出现在
我们面前的时候，大家都觉得这次需求很靠谱。
借鉴以往和产品人员打交道的经历过程中，反复是常有的现象。所以需求评审和基线化
是这个项目实施中最重要的实践活动之一。
六、 代码与发布
一个个的里程碑过去了，产品和研发的配合也越来越默契。
随着代码越来越多， 代码集成成了很大的问题， 每天依靠一个负责任的测试人员来管理
版本和编译打包有点落后了，为此引入一套自动打包和编译的工具很有必要。经过筛选，我
们引用了 Hudson 和 SVN 配合做自动化。在封闭开发期间，每天定时下午 6 点进行打包编
译，测试回归前一天的 Bug，开发工作按正常的进展进行。开发和测试之间的配合也越来越
默契了。
七、 总结会上
6 月底版本的测试结果并没有达到预定目标，最重要的指标——启动速度，还是没有达
标。经过反复的商议，我们决定延期项目，一定要拿出性能卓越的产品，所以才有了启动速
度最快的播放软件和画质提升显著的“左眼“技术的问世。
在 8 月份 Beta 版本发布后的 Sprint 总结会上，大家总结这次重构项目的得失，其中成
功经验最终被合并成了三条：
1、敏捷项目管理的实施让大家时刻关注目标；
2、测试把控质量标准严格；
3、所有人员以主人翁的姿态参与，大家都有了赢的欲望。
实践 健康 创新 家园

8. 群思荟萃
敏捷质量管理
P.S：要效率，也要质量，当敏捷试行，质量监控如何同步跟进？大连海辉软件(国际)
集团公司，质量与安全总监蔡德辉，10 月份做了一次线上的 PMBar 讲座，主题是《敏捷下
质量管理的问题》 ，受到社区的广泛好评，本期蔡德辉先生根据分享的内容，从敏捷模式质
量管理的根本原则到具体实践，由理论体系支撑结合实践，让大家进一步提升认识。
（一）敏捷质量管理的原则
核心观点：
灵活运用敏捷质量管理的最佳实践， 把这些最佳实践应用到敏捷过程中，能够有效地提
高效率，在迭代过程中不断改进质量。这些实践强调不断第反馈和证实，也有利于团队之间、
团队与客户和用户之间的不断交互，这些方法简单而实用，是敏捷开发成功的保证。
蔡德辉
海辉软件(国际)集团公司 质量与安全管理部 大连 116023
【摘要】本文讨论了敏捷质量管理的原则，从客户参与、过程驱动、预防、基于事实的
改进四个方面阐述了这些原则以及其再敏捷开发中的应用。并提出了一个敏捷和软件产品开
发结合的过程模型，供应用者参考。
【关键词】敏捷、质量管理原则、过程模型、敏捷度量
从 2001 年敏捷宣言发布至今已有 10 年时间，在这 10 年里，通过不断的鼓吹、打磨、
淬火，基于敏捷的软件开发已经成为主流的软件开发方法。以客户价值为导向，鼓励客户参
与、强调团队互动和可工作产品的敏捷得到了客户的青睐，并取得了很多成功的案例，这鼓
舞了更多的企业加入到敏捷的队伍中来，采用敏捷的方法实施软件项目。
敏捷是不是就不要过程，不要质量，不要数据，不要改进了呢？不是，敏捷强调的是快
速响应，强调的是价值驱动，现在敏捷的方法论无论 Scrum、XP、DSDM，更多是一个管理
框架，他们本身需要与软件工程、质量管理结合起来才能使用。敏捷从一开始就非常重视质
量，通过客户的深入参与、团队互动，迅速构建可工作的产品，得到了业界，特别是客户的
认可。这种快速反应，有利于更快地厘清需求，开发出可以使用的产品，得到客户和用户的
反馈，从而不断改进，这是开发产品的优秀的方法，但如果我们不适当地加以控制，就很可
能落入到需求不断变化、产品基础不稳、团队混乱的地步。为了防止出现这种情况，敏捷项
目应该遵循一些基本的质量管理原则。本文在实践的基础上，简单阐述以客户参与、过程驱
动、预防和基于事实改进这样的四大质量原则，希望能对大家有所帮助。
一、 客户参与
客户是谁？客户的目的是什么？我们为客户创造什么价值？我们应该如何与客户保持
协作？这是每个项目一开始就需要定义、分析、理解并在项目整个过程所贯彻实施和验证的。
敏捷四大宣言，将客户协作作为其中之一，可见其对客户的重视。客户在项目一开始得
到定义，并全程参与整个项目。团队在一开始应该理解客户的业务目标，理解项目为客户带
实践 健康 创新 家园

9. 群思荟萃
来的业务价值，理解客户的关注点，在整个项目过程中贯彻始终；客户在项目过程中，需要
明确项目的范围；决定需求的优先级；对实现后的成果进行确认与验收；及时反馈结果并进
行调整。这些要素突破了以往软件开发，客户草草提供需求，中期不管，后期才来验收导致
的沟通不畅，理解偏差等导致的问题。
二、 过程驱动
过程方法是现代质量管理的基石。只有通过系统的识别、定义、实施、改进过程，方能
够不断地提高效率、质量，达到最优。敏捷开发一开始提出四大宣言，其中第一条就提出个
体和互动，高于流程和工具。仿佛将过程打入了冷宫，这是对过程的误解。个体和互动本身
和流程并不矛盾。敏捷的大师们在经历了繁重的过程后，基于自己的工作经验，反思软件开
发的创新要求，提出个体和互动高于流程和工具这是可以理解的。他们认为对于创建软件产
品来说，创造、创新比过程更重要，而创造、创新更强调个体和互动。尽管如此，我们审视
软件产品开发的全过程，初级创意以及架构和高端的设计创造和创新占据主流，但当软件一
旦进入到细节设计、开发、测试等工作中后，尽管创造和创新还存在，但更多类似制造的工
作，而对于制造的工作，遵循过程是保证质量，提高效率的关键。
图 2-1 敏捷过程框架
在敏捷项目中，笨重的、纷繁复杂的过程，将被适应于敏捷的、更灵活的过程所代替。
这些过程一旦定义也需要得到遵守，并收集过程数据，并进行改进。例如定义一个 Story 的
实现过程，从需求理解、设计、实现、测试、Show、验收的过程。系统的定义过程，也有
利于团队进行沟通，确定团队所处的位置和状态，有利于培训与提高。
图 2-1 是基于敏捷的集成软件产品开发的基本过程模型。 该过程模型结合了产品开发的
要求，包括了管理与技术的评审点；提出了一些重要的整体过程，包括需求分析、架构、系
统设计与框架、以及后续的回归验证、系统集成测试、系统验收测试等内容，这部分内容代
表了对于产品来说， 高端的设计与思考是成功的关键，这些部分也可以组织为阶段或者迭代。
这对敏捷中迭代的划分提出了更符合产品开发的思考。 对于实施阶段，我们可能有多次迭代，
实践 健康 创新 家园

10. 群思荟萃
这些迭代的过程，也是清晰的，是团队应该遵守的。
三、 预防
传统软件开发方法过于重视测试的作用了，围绕测试甚至建立了 X 模型，将测试提到了
与开发过程的同等地位上，主要原因为:
1、由于软件开发本身的巨大不确定性导致的；
2、软件开发行业缺少好的缺陷预防的方法；
3、由于软件行业的从业人员本身的认识与素质造成的。
这三个原因，导致软件行业的质量成本超过 30%，有的甚至达到了 50%，这在传统行业
看来是不可思议的。
目前软件行业针对在三点也在展开研究：
针对第一点，目前开展的模式研究、成熟的基础框架、组件、SOA 等都是这方面的努力；
针对第二点，敏捷所推崇的客户的长期参与、测试驱动开发、持续集成、每日构建等最
佳实践，就是缺陷预防的方法；
对于第三点，需要教育、培训、企业和从业者共同努力。
预防重于纠错。从敏捷一诞生的时候，就贯彻了这个思想。作为从事敏捷工作的从业者，
要认识到其中的重要性，贯彻执行有关最佳实践。
敏捷软件开发围绕预防创造性的使用了诸如各种反讲、评审、原型、Show、客户的深
入参与、持续构建与集成、迭代回顾、可工作的软件等最佳实践，并综合运用各种工具来预
防、提高开发的质量，这些实践和工具被巧妙地安排在敏捷的全过程，较之传统软件开发通
过繁重的文档和评审更能够保证产品的质量。
四、 基于事实的改进
一个方法，一个过程必须要有能力不断学习，不断改进，才能够进化到最佳状态，并适
应环境的变化。改进也是现代质量管理最重要的要求。围绕改进已经形成了系统的定义过程、
实施度量分析、不断的改进并验证结果的完整方法论。我们只有搞清楚了生产率、成本、缺
陷率等指标，才能够有效的度量出现在的状态，未来的改进方向和改进的效果。
软件行业从诞生开始就受到一个困扰，那就是数据不足。没有数据，何谈改进。如何使
软件行业的从业者能够有效的收集与提供成本、规模、工时、工期、缺陷等数据成为目前软
件行业的难点。这也是一个行业成熟的标志。不管是敏捷还是其他方法论，都必须支持这一
点，否则没有改进，就只有消亡。
敏捷软件开发每次迭代的周期比较短，我们可以在每次迭代中收集质量、成本、进度等
数据，并在迭代结束时的回顾会议上进行分析与讨论，使项目组能够清楚的把握自身的能力、
产品的质量，并分析需要改进的过程和方法。
关于敏捷如何度量，最近在敏捷业界引起了广泛的讨论，Esther Derby 在“敏捷的度量”
文章中提议度量下列指标：
 修理缺陷工作量和开发新特性工作量的比率
实践 健康 创新 家园

11. 群思荟萃
 周期时间
 遗漏到产品中的缺陷
Isaac Montgomery 则在“衡量敏捷投资的影响”中建议采用的指标下面的指标：
 生产率
 质量
 反应速度
 客户满意度
 员工满意度
 可预测性
通过实践，我们建议的对项目执行结果的度量指标如下：
 客户满意度
 交付质量
 按时交付率
 按时响应率
 团队满意度
 成本（或者毛利率）
 生产率
不管我们采用哪些指标，我们需要非常关心数据的采集方法和度量与分析的时刻。考虑
到敏捷的特性，建议是在每个迭代过程中进行采集与度量，在迭代回顾会议上进行分析，并
制定策略进行改进。
除结果指标以外，我们有的时候会需要过程的指标来保证我们的结果能够达到，常见的
过程指标包括代码的抽检率、设计评审缺陷率或者测试覆盖度、代码的圈复杂度等，这些过
程指标如果要采用，一定要保证团队能够充分认识到他们的作用，在工作中不需要做太特殊
的工作就可以做到。
在进行数据收集、度量分析与改进的时候，要注意不要认为引入过多的指标而成为累赘，
是否采用某个指标，取决于项目的情况，这需要在计划阶段进行决策。
【总结】
客户参与使团队总是关注在价值最高的事情上，并不断推出可以使用的软件而不断获得
反馈；过程驱动使团队能够协调一致、进退有据，更利于管理和提升效率；预防是获得高质
量产品的关键；基于事实的改进为这些提供依据，这四项质量管理的原则与敏捷思想的有机
结合，可以使敏捷开发更有效率、质量更高、过程更可控。
如何有效的应用这些质量管理原则，敬请关注本系列之二：敏捷质量管理最佳实践。
【参考文献】
[1] Ken Schwaber 著 李国彪译 Scrum 敏捷项目管理 北京 清华大学出版社 2007.
实践 健康 创新 家园

12. 群思荟萃
[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/
实践 健康 创新 家园

13. 群思荟萃
（二）敏捷质量管理最佳实践
蔡德辉
海辉软件(国际)集团公司 质量与安全管理部 大连 116023
【摘要】本文讨论了敏捷质量管理的最佳实践，包括需求控制、架构设计与反讲，团队
设计与串讲、模式应用、Code Review、Show、成果限样确认、工具应用等 8 个最佳实践。
这些最佳实践被应用在迭代过程中，为提高产品质量、提高效率起到了关键作用。
【关键词】敏捷、质量管理、最佳实践
团队在敏捷质量的四项原则基础上，需要遵守质量计划、质量控制、质量保证与质量改
进的质量管理过程，将质量管理过程的要求，融入敏捷的要素，形成了自己独有的最佳实践。
对这些实践的灵活运用，可以开发出质量高而稳定的软件产品。
一、 需求控制
Standish Group 每两年一次发布的 Chaos 报告中，软件项目的成功率都是很低的，1994
年为 16%，2008 年为 32%，而给出的项目失败的原因中有超过 50%与需求有关，可见做好
需求控制对软件项目来说至关重要。
敏捷开发推崇客户的广泛参与、反馈、可以工作的软件、 通过产品 Backlog 和迭代 Backlog
的方式来进行需求管理，这很好的响应了 Standish Group 提出的十大成功要素中用户参与、
清晰的业务目标的两个目标。
在敏捷中实施需求管理，需要遵循记录、分
析、复述、原型、估算、实施、核实这样的 7 个
步骤。复述、原型就是非常重要的质量保证方法。
无论在什么样的工作环境下，返工永远是成
本最高的，而复述和原型可以防止需求理解错误
导致的返工。复述就是客户讲完以后，项目组按
照理解重讲一遍，客户再确认，双方不断的讨论
最后达成一致。
原型是在这之后进一步的确认，有的需求，
客户过一段时间可能会有一些新的看法，在原型
阶段就可以及时反馈，而原型才是最终软件交付
后的样子，也可以让客户尽早看到工作的样子，从而再次讨论。
有的敏捷方法如 Scrum 中，认为在一次迭代中，需求变更是不允许的。这个提法有点
绝对，应该从两个方面来看，一方面就是从大的方面来说，在确定好迭代的 Backlog 以后，
这个范围应该是被严格控制的，如果要发生变更，则要考虑取消迭代，因为迭代本身周期很
短，如果折腾一次不值得了， 不如干脆重来；另外一方面，某一个特性的内部细节发生变化，
这应该是被允许的。因为客户毕竟不是软件专家，他所想象的系统的行为，可能和我们的理
解不一致，因此这个变化是不可避免的。问题是项目组要能够判断这个变化对迭代的影响，
最好控制在 10%以内。
实践 健康 创新 家园

14. 群思荟萃
二、 架构设计与反讲
架构是一个软件的基石，尽管架构的发展也会随着项目的变化而变化，但一开始尽可能
设计与实现一个完善的架构，是任何一个软件项目要追求的。没有良好架构的软件，就是没
有打好基础的摩天大楼。只是软件和摩天大楼的不同处是，软件的架构可以在一定的范围内
演化。尽管如此，也不意味着不要求设计完善的架构。随着模式的发展，架构设计也越来越
有迹可循，这会提高软件项目的成功率。
敏捷项目通过迭代来组织项目的进程，迭代本身可以划分为需求迭代、架构迭代、整体
设计迭代、N 次功能迭代、特殊迭代、测试和验证迭代等很多类别。架构迭代应该是其中非
常重要的迭代。
尽管架构本身对设计师的要求很高，但大部分项目组成员只需要理解和应用架构。 问题
是，他们真的理解架构了吗？为此我们有必要设计一种质量保证方法来保证团队真的理解了
架构，这个方法就是架构反讲。架构设计师或者主设计师向团队讲述与演示了架构以后，每
个团队成员要根据自己的理解重新讲述一遍，然后大家一起来进行 Review，找出正确与错
误的地方，不断调整，直至完全正确。团队成员在这个过程中能够迅速的认识未来系统将如
何发展，系统的质量能够得到保证，成员的能力也会迅速提升。
三、 团队设计与串讲
尽管我们期望团队的成员都是训练有素的，每个人都已经能够完成自己的工作。事实上
我们组建的团队一开始能力差异很大，如何才能保证交付的质量？敏捷希望每个团队成员都
了解系统的结构，都能够进行设计、开发、验证。这就要求我们必须有一种方式，能够弥补
由于个人的能力不足导致的问题。
这个方法就是团队设计和设计串讲。我们将设计过程调整为：首先，团队一起讨论本轮
迭代的整体设计，系统将如何演变来满足本轮需求的需要；然后对每个 Story 进行讨论，形
成设计方案；然后负责 Story 的人在会后将设计方案进行完善；最后再组织团队会议， Story
由
负责人进行设计讲解。 这个团队设计与设计串讲过程能够迅速提升团队的设计能力， 也能够
有效地保证产品的质量。
四、 模式应用
业内提到模式，通常让人想起设计模式，其实设计模式只是软件众多模式的一种。
模式是对常见问题解决方案的总结，目前模式的范畴很广，覆盖了软件开发的各个部分，
业务、需求、架构、设计、代码、测试、用户习惯等都总结了出了相应的模式。模式中提出
的解决方案，都是经过了多次验证，只要使用得当，就可以做到缺陷少，效率高。
模式的采用，也能够快速的提高效率，改善沟通。敏捷开发的倡导者都是现代软件开发
思想的鼓动者，他们中很多人都是模式的专家，致力于推动软件社区来接受、使用、总结新
的模式。作为敏捷的应用者，由于追求较少的文档，敏捷的过程，模式的应用是非常关键的。
较少的文档，不代表较少的设计，使用模式是有效降低设计难度，减少文档的关键，也是提
高软件质量关键。
实践 健康 创新 家园

15. 群思荟萃
模式可以重复使用和改进，模式本身又是通过了验证的解决方案，因此模式的应用也是
缺陷预防的重点。
五、 Code Review
Code Review 可以划分为自检、互检、小组评审三种形式。
开发人员应该养成编码完成后进行 Review 的习惯，一方面检查各种风格、格式等简单
的问题；另外一方面从设计出发重新检视代码，保证达成设计要求；另外需要在 Review 中
不断的询问自己更简单、更有效的方法，不断优化代码。 敏捷强调代码要简单、易读、易懂，
要做到这三点不容易，一般在第一遍编写代码的时候，考虑的是如何实现，只有在 Review
代码时才会考虑其他问题，因此多次自检对程序员来说是很重要的。
互检可以发现自检发现不了的问题，有的时候程序员会对自己放松要求，通过互检就能
很好的检验合规性、符合设计、优化、简单、易读、易懂的要求。如果互检的时候，对方都
看不懂，那么代码肯定要进行修改。互检的时候，也能相互学习，快速提高。
小组评审在团队成员能力不足的时候用得比较多，小组评审需要评审成员提前阅读代码，
标记疑问，评审的时候提出来，这将消耗一些时间，但是大家可以从小组评审中迅速提高自
己的能力。
做 Code review 一般较难记录所有的缺陷，最好准备好一个常见缺陷清单，原本是在开
发前使用的，用来做缺陷预防，但现在可以用来做快速的缺陷记录，遇到问题，只要画正字
或者打钩就可以，这有利于后期进行分析和改进，也可以改进缺陷预防表。预防缺陷产生的
成本总是比较低的，缺陷一旦产生，记录、重现、定位、修复、验证、展开的过程非常的耗
费时间，因此 Code review 较后期的测试能够更节省时间。
六、 Show
向客户展示系统就是迭代 Show，向团队展示某个 Story 就是 Story Show。Show 本身是
实践 健康 创新 家园

16. 群思荟萃
很简单的，但 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/.
实践 健康 创新 家园

17. 群思荟萃
[6]丹尼尔.弗里德曼 杰拉尔德.温伯格著 唐云深 胡庆培译 走查、审查与技术复审手册
—对程序、项目与产品进行评估 第三版 北京 清华大学出版社 2003
【编后语】作为敏捷质量管理在线讲座的总结，蔡德辉先生先后绘制了两份质量框架图
示，还在继续完善中，在编辑的鼓励之下，蔡先生同意先发表出来引发大家的思考和碰撞。
以可工作软件为核心的敏捷质量管理体系
以团队为核心的敏捷质量管理体系
实践 健康 创新 家园

18. 群思荟萃
微观点
围绕“传统，敏捷，你在什么位置？”，除了我们从因敏捷与 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】
#用例和用户故事#用例本身的局限性在于它仅对“功能需求（或称行为需求）”更合用，
实践 健康 创新 家园

19. 群思荟萃
而用户故事倒可以摆脱这样的困难。用户故事的局限性在于对于较大规模系统时，使用者很
难有效地保障其完整性。
【徐毅 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】
对于一个团队你是不是敏捷了我不在乎，我在乎你有木有用科学的方法解决项目中的问
题了？团队成员能力提高了木有？用户对我们产品的反馈变好了木有？团队效率提高了木
实践 健康 创新 家园

20. 群思荟萃
有？产品质量提高了木有？如果你采用了敏捷方法，你的团队可以快速迭代木有？你的项目
始终做最有价值的事情了木有？
｛出处：http://weibo.com/1495430110/xshERujt0 }
【张克强 2011-10-11】
#敏捷改进#的状态应当是很微妙的平衡，既不是在重重已定义过程范围内照着做，也不
是没有已定义过程随意的做，而是位于边界处，以开放的心态，以已经存在的现状和已定义
过程为基础，向着组织商业目标，探索新的更好的做法，可以参考业内公开的有效方法实践。
五、 {产品管理
｛出处：http://weibo.com/1907298003/xpwWXkzwp }
【陈勇 2011-10-06】
无论有多少种方法对优先级进行排序，作为产品而言，都永远应该把最体现差异化价值
观的功能置于万事之前。作为项目开发而言，则应该把造价估算和跟踪置于万事之前。
敏捷方法实践话题非常多，即便是专家之语，也不见得就是完全正确的，如果您对上述
话题感兴趣（不限于上述话题），可以在主群、水群、微博上继续深度交流，PMBar 也将继
续关注敏捷，敬请广大读者积极投稿，投稿地址是 editor@pmbar.net，写出您的心得，分享
您的实践，期待您的亮剑……
【本期《群思荟萃》责任编辑张权，感谢 陈勇 对本栏目的采编、审校】
实践 健康 创新 家园

21. 项目案例
【项目案例】
【编按】：需求，变了又变，还不给加钱；代码，改了再改，还问题越来越多；沟通，
电话、邮件，仍无穷无止„„作为项目经理，每天都会遇到一些棘手而又不得不面对的问题，
你需要急中生智、审时度势、果断决策，还需要灵活应变，善于周旋，一些问题普遍存在，
又都各有不同。如何披荆斩棘，拾阶而上？本栏目摘录一线现场的真实场景还原，典型问题
的不同处理， 资深经理们的众说纷坛。关于进度、沟通、决策、补救；关于为人处事的洞察。
希望能带给您多少的启发。
经验沉淀、汇聚便是财富，难题困扰这里有专家出谋划策，欢迎您的分享、参与。
案例一：如何进行集团内部招投标项目的开发实施？
案例提供 / 谷雨霖
行业：IT
项目阶段：执行阶段
项目背景：
一个内部招投标的项目，招标时加上了日常管理这个部分。日常管理包括 ABCDEFGH...
十几个子功能模块,标价只占 7 万。每个子功能的业务由客户单位不同的人员分别负责，只
能分别调研，每个人都对系统提出了不同的要求，恨不得实现 100%的完全信息化。由于内
部单位，我司不好拒绝，后期还希望他们帮我们推广说好话。我方经过努力开发，基本完成
任务，成本早就远远超过 7 万。结果十几个子功能模块只有 5%的功能得到使用，其余全部
闲置,开发人员积极性受打击。验收推进缓慢(目前已经验收)，还时不时冒出新的需求要求继
续开发，满意度也不高。因为后期希望他们帮我们推广说好话，项目经理没法不答应。客户
领导甚至暗语我们送给他们一些设备，老板也答应了。目前又到了签订维保合同的时候，客
户继续以新的需求为条件才答应。事实上，系统一个也没有推广出去。
分析要点：
1.请指出项目中出现的问题及原因?
2.正确的做法应该是什么?
3.目前应该怎么办?
问诊出谋，众说纷纭
 马兆林-cio-京 说:
把这个“日常管理”模块单独拿出来，其它部分先验收；否则会影响整个项目的进度，
甲方也会不满意的。如果合同已打包，则加签补充协议。要做甲方的工作，不能因为局部影
响全面，也会影响甲方的进度，站在甲方的立场。
1）首先甲方对 IT 的实现认识有问题，不能解决全部问题；
2）甲方对自己要什么不清楚，变更快；
3）乙方无限制的答应开发，没有自己的判断和项目管理。
实践 健康 创新 家园

22. 项目案例
结论：
1）项目下马，乙方不要在投入录入，无底洞；
2）提升甲方的 IT 认知，我管它叫甲方的 T 商，最好甲方有个项目管理的明白人沟通，
当然这个人还要有强势和决策权重，这方面条件具备了，再谈需求细节。锁定需求，双方确
认开发任务和工作量；
3）对于这类客户，需要乙方有优秀的项目经理。
 Hawk-PM-苏州 说:
PM 发正式通知，需求收集截止时间是什么时候，过了这个时间，不再接受新需求，否
则案子只能一直做下去了
 Ted-项目经理-北京 说:
设定单一接口，严格执行变更流程，设定验收标准。
让客户明确需求目的，大量的时间，精力花费在无用的功能上，导致项目延期对他们也
是损失。
 邓超-开发-上海 说:
个人感觉 要先把分散的需求集中化，把相关的业务单位召集在一起 先整理整体的业务
流程
提出一个合理化的建议，然后再来做系统的需求。
 Microhui-PM-上海 说:
PMP 课上老师说过，项目主观是满足干系人满意，客观是实现项目目标。但是主观比
客观重要。这儿的干系人没搞清楚，所以需求收集的不准确。
 老张-技术总监-bj 说:
需求，先由甲方评议后，统一有接口人 open 出来，并定义优先级和验收标准。
标准，一开始就很难定义清楚，需要逐步明确，现在基本上是死一个项目经理的代价，
坚持了这么长时间，应该可以谈验收标准了。
 谷雨霖 说:
这里面我个人认为有这几点问题：
1）集团需求引导不到位，要通过咨询来确定总体和分期目标，限定到小范围；冰冻三
尺非一日之寒，信息化建设需要徐徐渐进，不可能一步到位，更何况，人们的意识可能离成
熟还早的很分期开发对项目收款也是非常有帮助，不能将运营类内容，放到项目系统中来，
否则固定价合同只有死路一条。
2）在子系统发中，要设定标准，减少定制化（争取非固定价格合同）
所谓设标准，这对集团公司非常有意义，特别是国有集团公司。在集团公司做人是第一
位，做事是第二位，所谓责任第一，无责原则下才做事。那么如何才能无责做 IT 建设，就
需要树立标杆这个标杆一定是整体利益最大化下的产物，然后以此号令诸侯，杜绝或者限定
子公司的个性化需求。个性化需求不符合标杆，就是触动利益线，就是要担责任。通常，大
家都会收口。不收口，也会限定需求，或自己额外付费
实践 健康 创新 家园

23. 项目案例
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 火力不够强大
实践 健康 创新 家园

24. 项目案例
急救措施要果断
 Microhui-PM-上海 说:
我也想知道：
如果你是现在的项目的 PM，该怎么办？
如果你是空降的那个，估计就是第二个死的 PM
超-技术负责-深圳 说:捋顺关系，掌握手里现有的资源吧。
 老张-技术总监-bj 说:
措施一：暂停开发，分析现有需求哪些已经实现，哪些未实现；
措施二：看看手边资源哪些还能用；
措施三：确定需求搜集机制。
由甲方对未实现需求进行排序，确定开发重点，每周定期搜集并讨论需求，每周发布一
次。
 恺墨-CTO-北京 说:
我会重新火力侦查，调整进攻点。先确定老板还有没有决心支持，没有老板的支持，
趁早收手。
 谷雨霖 说:
这个项目需要做个项目现状报告，乙方高管和甲方做深入沟通，看能否争取费用。如
果做不到，失败是必然。
 马兆林-cio-京 说:
先看目标偏离，然后看看人力资源，不要逞能，首先判断项目有没有继续的意义。
及时沟通很重要
 超-开发-上海 说:
个我的想法：把需求重新整理，然后标明是谁提出的，然后定期公布给项目的干系人。
因为大型企业里面，提出需求的人 有时候会担心有责任的问题，通过把需求公开化，
来控制他们各自的需求的边界。
 Ted-项目经理-北京 说:
这个项目需要乙方高管和甲方高管好好谈一谈才行
一般甲方的高管还是很明事理的，下边的小兵都很难缠
 马兆林-cio-京 说:
我做项目经理时，发周报发给项目所有参与人，让大家知道他们的需求开发到哪一步了，
不会存在任何信息死角。
周报的发放对象，从董事长到 基层甲方业务人员，这样大家都看到进展，成就属于大
实践 健康 创新 家园

25. 项目案例
家。
还有就是签字制度，在于坚持执行，需求，验收都签字。
 Microhui-PM-上海 说:
项目的成功与否，跟一个优秀的项目经理有很大关系， 马总做到的，只不过是 PM 的
基本素质-沟通，但它占的比重是 85%
 老张-技术总监-bj 说:
关于需求沟通，需求提出人、甲方接口人，乙方接口人，乙方开发人，需要宣讲、Review，
最后才敢签字落实，双方沟通无误，是需要技巧的。
 超-技术负责-深圳 说:
对，要落实下每个阶段的成果，然后周报展现，每个人都知道项目的进展，这样的东
西甲方看的也觉得实实在在，尤其是国企 ，有时候他们是需要政绩和实物来说明，他们也
要跟上层汇报的。
案例二：企业项目中的技术决策
主题：企业应用软件开发项目中的技术决策
导入：
企业级开发与其它软件项目如通信、互联网相比，有几个不同的特征：
1. 它直接面向客户；2.它有不亚于软件开发本身的业务专业深度；3.所以，客户
与开发团队在对同一问题上强烈的认知冲突是直接产生的，面对一个项目要正常地进行
下去，首先就要解决认知上的冲突，作为技术决策者，需要平衡各方面的因素。
第一个要抓紧的东西是：计划和进度——在这个项目里，先做哪些部分，再做哪些
部分，每个部分完成的里程碑在哪里。第二个要抓紧的东西是：团队综合技术水平，当
前能做什么，在接下来的时间怎样配合项目提高综合技术水平。
场景 1：设计决策，洞悉核心
一个遗留的供应商管理系统，数据库结构既定，程序既定，要实现一个供应商地址簿的
功能，查询却发现数据结构不支持多地址、 多联系人设计； 界面是 CS 架构，非常多的控件，
到处都在加载。这在开始时是一个很小的项目，预算大概就是 1 人 1 周左右的开发时间。怎
么做，如何做，它是技术决策中最初等，也是最常见的决策方案：主程序员决策。这个系统
的维护团队（负责所有新需求的开发）的主程序员根据需求，设计了一个地址簿模块程序。
那是一个很炫的程序：它有卡片式的名片翻查，客户非常着迷，决定就这样办。而项目是按
开发时间收费的，所以，这个设计是有利于团队的，因为客户愿意为它增加预算。这样，因
为技术方案，项目的规模扩大到了约 2~3 周。但在开发时发现，旧的程序框架使用的数据持
久化方式和绑定数据的方式太不灵活了， 它是基于 DataSet 的，需要进行很多的编码； 另外，
旧的控件呈现方案也不利于卡片的展现。 这时主程序员决定对整体的数据库持久方案和界面
呈现进行重构，改写成更灵活的 OO 方式。 最终的编程模式定义为 Observer Pattern——观察
者模式。在这个方案敲定之后，项目经理与客户协商，延期至 1 个月，理由是原方案可以提
实践 健康 创新 家园

26. 项目案例
供更好的业务功能扩展性，因为客户对旧的程序运行速度也忧郁很久了，于是客户同意了。
经过大约 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 是个综合岗位，需求分析和对
业务流程的把控是能力的一部分
实践 健康 创新 家园

27. 项目案例
场景 2：技术决策，“活在当下”
。
接下来我们看第二个案例吧，它是一个很大的平台，由两家供应商公司开发，各自负责
一部分，最终进行功能上的集成。
这是一个外包项目，项目经理、需求分析师、开发团队 1、开发团队 2 都来自于不同的
公司。大家都有自己的算盘(rotfl)都想取得利益最大化。
计划和进度，就决定了交付压力和客户的反馈，这都会影响到各家的表现。
首先，客户有自己的计划表，这来自于他们的 IT 规划；其次，项目经理有一份计划表，
这来自于各个资源的到达时间和完成速度；再次，需求分析师也有一份计划表，这来自于他
约见需求确认对象的日程表„„
这个冲突持续了三个月，在三个月内，项目几乎没有任何进展，客户每次都在催问：什
么时候可以看到系统？
其实系统连个种子都没有„„它是一个全新的项目，谁都不知道它该长成什么样，从业
务应用上来说它也几乎没有可参考的，这是一个关于资金的投资计划的系统。
技术是什么？不是最终写出来的什么代码，使用了什么框架，而是针对客户业务的技术
解决方案。
需求用例不足以形成一个系统，就像“制冷需求”无法设计出冰箱一样，它只会说有冰
棍或食物需要冷藏，但多少摄氏度，需要几个门、有没有抽屉、隔板用什么材料、制冷加不
加氟利昂，用户需求能描述吗？
这才是技术的核心，技术不是编码，就像冰箱的制成方案不是工厂组装一样。需求用例
是用原型法来定义需求，它是方法，并不是需求本身。在这个项目中，首先要解决的问题，
就是为客户定义他们需要的是一个什么样的系统，业务需求和规约都是后面细节上的问题了。
这个“什么样的系统”问题回答者，项目管理范畴做不了，需求分析的范畴也做不了，它需
要的是一个技术决策者，无论他正处于什么样的职能。这个问题被回答了，事实上项目的范
畴和需求分析的范畴才真正确定下来。
在企业项目中，在有全新的需求时，谁应该去回答“开发什么样的系统”？这个问题你
们有没有答案？
那就是一群人来回答？
一群人的结果就是这个案例的前三个月，没有进展，项目面临全体下课。
这个问题本身是一个业务问题，因而业务需求的提出者更可能适合回答这一问题。
甲方的 PM 应该最了解自己要什么，或者经过市场调研后，定位于接近的产品，无非
就是 ERP，CRM。
还是可以归类的， 之所以不是组织的原因也在于：单个供应商从能力上几乎无法承担这
样的项目 。甲方的情况是，他们是一群投资预算小精英，对软件甚至业务流程一无所知，
“甲方 PM”的概念更是无解，他们会回答：雇用你们 PM 就是做项目管理。他们只会用这
样的方式来解决问题：你们做不好，谁做不好就换谁，换分析师、换 PM、全体做不好就换
供应商。
实践 健康 创新 家园

28. 项目案例
他们是不愿意参与到项目实务中来的是的，风险很大的项目，所以才拉了一群来共同承
担风险。这就是所谓外包中“背靠背”的方式，不知道你们是否很常见。
大部分技术人员包括架构师在遇到这样的项目时，采取的姿态都是被动等待。等待需求
文档。他们没有意识到，这时候最需要的就是一个能够构建系统的人参与进来，为客户提供
系统方案。承担这个角色的应该是一个有丰富经验的系统架构师。
首先需要了解的是客户为什么有这样的需求。
客户产生这个需求的原因是他们做了投资预算之后产生的后续业务已经有系统了。
他们做为这些业务系统的部分权限使用者，发现许多功能是残缺的，没有他们想要的功
能，没有想看到的数据。这个后果是肯定的——因为那些业务系统又不是为他们开发的，只
是它的所有业务部门为他们开放了部分权限。 作为甲方的几个部门，他们采取的第一个动作
就是去争夺这些已有的系统，他们认为这个系统应该属于自己，然后就开始了高层领导的
PK„„
PK 的结果就是继续 PK 并且立即雇用一个团队来把那个系统改成自己想要的样子。
在前三个月，需求分析师和项目经理的时间基本上都花在说服原系统的业务部门接受自
己雇主的需求修改上了，这时候架构师参与了进来，初步达成的意向就是新开发一个平台，
使用共享中心业务数据库的方式来实现数据共享，就是这样简单的一个改变，直接就把两个
部门的争执平息了，这时候雇主部门才意识到自己需要的东西是投资计划平台，接下来就简
单了，大家一致朝这个方向前进。
企业项目从最开始，它表现的不是一个技术问题，而是一个愿景或业务问题。
这个实现非常简单，但定义它是一个什么样的技术问题本身不简单。
大部分项目都是扑朔迷离，如果技术人员从需求分析师、PM 那里被动传达要求，而不
是与客户坐下来讨论问题，最后的技术方案一定会失败。
SO，这个项目进入了正式的开发计划，又遇到了新的大难题。
客户在很高兴的情况下向领导一汇报， 然后领导提出了自己对这个系统的需求，这时候，
客户就要求首先开发领导的需求了，整个项目计划表被全部重排，领导的需求就是报表。此
时的情况是：系统都还没有，怎么办？整个团队刚刚才坐稳屁股，这时候最不敢惹客户。此
前领导还在前方 PK 这时才真正开始提业务需求。
解决一切问题的根本就是从实际出发，没有任何凭空产生的问题， 领导需要看到的报
表，其实是当前就有的，只是它是以员工通过 Excel 编辑产生，既然现在有了系统，大家自
然会把这个功能放在系统报表里。
当前最好的技术解决办法， 就是着手设计报表专用的数据库，将已有的 Excel 数据导入，
然后从报表数据库中产生报表。 这个技术方案与整个系统设计方案只有 1 个关系， 就是报表
数据库，这样不共享任何东西，便于分别独立开发，同时也分清责任。这里对报表数据源其
实有三个方案：1.业务数据库 2.报表数据库 3.数据仓库
业务数据库的难点在于，需求细节不清楚的情况下无法做设计，粗糙的设计即使满足了
报表需求，未来的变更影响所有的开发和报表程序本身数据仓库的问题在于客户需要采购新
实践 健康 创新 家园

29. 项目案例
的软件，对开发人员有新的要求，以及预计的数据规模不大。
最后就采取了一个中间数据库专为报表开发，既支持读取存储 Excel，也能从以后的业
务数据库同步数据。
这个方案又押对了宝，仅仅两周就开发结束，并且期间不断与客户互动，客户整理数据
不亦乐乎，建立起了信任关系，接下来，开发团队分了一个人手，专门在每周维护 Excel 的
数据导入，其它人进入系统开发直至上线。项目出现什么差错都不是大问题了，客户越来越
好说话，最后的结果是整个系统的报表处理技术在不断升级，而已，项目圆满结束。
关于需求本身，他们说：
 陈加兴-研发经理-成... 说:
第二个案例是一个基于业务的技术决策，它是典型的“活在当下”
。
许多谈话中的决定性细节，需求人员和 PM 缺乏技术敏感性，除非客户需要的不是一个
技术方案，技术敏感性的缺乏是致命的，比如：错误的计划表、错误的工作量估算，大部分
需求的记录是从客户的角度，而不是系统开发所需要了解的全部需求。
 wenjin.xu-IT Cons... 说:
这在中国某些政府项目中 特别明显, 政府项目的乙方喜欢拉上 IBM,MS 等一流公司陪
绑,如果出了问题可以由他们背黑锅,(或间接证明项目没法做的,你看人家世界一流的公司都
没做出来)
 马兆林-cio-北京，新... 说:
我经常讲，软件就想盖大楼，干什么大楼没搞清楚，我是不盖的。这个大楼是酒店，工
厂，民宅？是仓库？你先给我讲清楚，图纸我画给你，厨房什么样？马桶在哪，必须签字确
认！如果是大型高级应用，甲方应该配备自己合格的 PM，完全交给乙方，风险不可想象。
从 case2 的“投资计划平台”定性看，不是 IT 问题，是甲方开始想通过乙方 回答自己
要什么，但前期代价很大， 很幸运，乙方来个解惑的 架构师。 但架构师真的不是 解决“投
资计划平台”定性的途径。 也许这个架构师炒股或者做过会计，投资项目，否则这个问题
还解决不了。 甲方的出发点错了。 乙方为了争夺项目 做了很多无用功。 社会资源的浪费。
所以后面的报表开发的问题出来了， 这个实施商根本可能就没有相关经验， 一个架构师不是
一个实施团队。
 wenjin.xu-IT Cons... 说:
需求方面 应该是乙方去采集,甲方一般没有系统的概念, 需求分析人员要承担需求分析
的工作, 初期技术人员只要确定技术可行么?能实施么? 时间要多久这些专业方面的建议。
而且在初期需求不确认的情况下,给出的工作量必然也是有误差的,这要随着需求和文档
的进一步细化才会越来越精确。
这就是分析人员要有技术背景,或者要有技术人员在早期参与评估。
 Michael-PM-厦门 说:
技术决策首先需要完整、准确收集需求，其次需要一个经验丰富的架构师或需求分析师，
最后给出一个经济、适合的技术方案，对项目负面风险影响最小的方案。但是，当下究竟是
实践 健康 创新 家园

30. 项目案例
一个什么样的问题，这个问题定义本身就是一个技术活。在开始，它是一个迷团，你唯一能
听到的就是持续不断的争吵声，随后就是各方面施加的压力。
这是最考虑一个决策者的部分。需要让各方冷静下来，让各方都满意。
具体到需求收集：一、甲方的项目发起者或者说领导的推动力不够，二、项目的组织角
色、责任需要明确，三、无论是任何项目，甲方都不可能摘出自己，因为再有经验的乙方架
构师都不可能凭空给出需求。
这完全是需求的问题, 乙方需求人员没有帮助甲方确定需求，确定什么是乙方想要的，
确定什么是甲方想要的。
在需求问题上，甲方需要做两件事，一是配合乙方收集需求，二是拍板签字；而乙方要
做的是把甲方的愿景转换成技术的、可描述的、可执行的具体需求。
 泳菲-pm-北京 说:
我经历过类似的情况，甲方老板想做一个项目想了很久了。然后就是甲方各个部门的讨
论与博弈。
讨论了一年，没有任何动静。需求文档出了很多版本。但是系统什么时候开发一直也没
定下来。后来，公司来了一个项目经理，了解情况后，不在组织任何的讨论与扯皮。对原来
讨论的文档研究了一下，立即组织开发人员开发 DEMO。一个月后。DEMO 获得老板好评，
项目资金马上到位并开始开发。最后结果是，老板大力支持项目。原来很多扯皮的部门与领
导也不得不出来支持。很多原来扯皮的矛盾渐渐化解。
现在很多项目就是这样。如果要把需求讨论清楚。项目就是无法开工。
 兔子瞧-PMO 顾问-北... 说:
我觉得更致命的是分析的时候对业务缺乏框架思考的能力。只要框架不设计错，技术上
不会有太大的问题。现在很多需求设计人员只会需求功能的分析，而不是业务设计。
这个时候还在评估阶段, 技术人员要对技术风险,现有团队 开发时间等作出较为准确的
判断, 不然后面就惨了。
 蔡德辉-PMO-大连 说:
不管在什么情况下，在需求方面，客户、开发商之间要良性互动，用客户懂的方式，描
述业务需求，或者实现业务需求；用设计人员懂的方式，描述技术需求。至于技术的决策，
如果是做应用，应该是比较快的，当然建立在有经验的基础上，但不追求过分的完美与细节。
这种局面 99%的解决方式都是抛弃所有局内人姿态，因为他们本身就已经在冲突了，不
换思路只有继续冲突下去。
场景 3：挑战新设计 比较成功
这里的技术决策是企业项目，是有一个背景的。背景不同，影响决策的因素就不一样了。
好，我分享第三个案例吧，这个相对比较成功。它是我现在在做的项目，带领一个团队
用完全不熟悉的框架和设计思路做事，包括 ORM、容器、TDD、DDD 等，技术决策者需要
的是专业，还有权力，没有权力，就得运用影响力，否则是谈不上决策的， 那只叫发表意见。
实践 健康 创新 家园

31. 项目案例
对开发中常用的框架，其实企业项目运用到今天，已经非常成熟了，决定要快，学习要
抓， 遇到问题强调相互解决，就会产生一个上等的决策结果。实质就是不管你选择哪种框架，
路都是可以走通的，这个“技术”不是核心。其次就是开发中采取的开方思想，比如 OO、
TDD、PP，开发思想或编程思路，我认为它是程序员个人化的东西
它无法“被决策”，为什么？因为不懂的人，无论如何都做不了。钻木取火、火柴、打
火机都是点火，不必强求。当然成功点火的时间都有差别就是了。对，如果要使用不熟悉的
东西，需要有一个学习计划表，但是思想很难被学习，需要一定的理解能力。所以才有这么
多的框架，框架使用起来很简单，但你让程序员描述 spring 中各个设计思想，然后让他们自
己实现，就非常难，与个体强关联的部分如何做决策？答案是： 因人而异。对软件开发来说，
做到一致的代码编写规范，模块划分合理即可，这个是任何程序员都能够做到的。
关于技术决策时考虑因素：
1．任务紧急时，要抓紧的东西是：计划和进度——在这个项目里，先做哪些部分，再
做哪些部分，每个部分完成的里程碑在哪里；
2．重构代码时，要抓紧的东西是：团队综合技术水平，当前能做什么，在接下来的时
间怎样配合项目提高综合技术水平 ；这是一个技术决策者在作出正确的技术决策之前必须
了解的东西，无论它是正式的文档还是私人的交流，它都必须准确真实、第一手。如何去获
取，自己想办法。
技术决策的几种常用方法：
1.主程序员决策：由团队中担任主力设计或开发的人来决策；
2.效率高手决策：由团队中完成任务速度最快的人来决策；
3.矩阵式决策。
每个决策方式都有特定的场景，具体的应用还需要根据实际情况灵活应变。变是永恒，
适者生存。
 Michael-PM-厦门 说:
无论是谁来决策，都必须通盘考虑，不能从自己能力出发，因为别人有可能达不到主程
序员的水平，也没有效率高手那么有效率。
实践 健康 创新 家园

32. 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 版本客户也应该是接受的）
才发布，延期一周。
为了规避需求风险和技术风险， 月 4 日－7 月 8 日，需求开发人员天天缠着客户（mm
7
就有这样的好处了，换成个大男人天天缠人就不太好了）确认需求，同时组织技术评审，定
好大体的开发和技术框架。
由于不熟悉业务，只得采用驻客户现场开发的方式，但有些团队成员（1 高级程序员，
2 中级程序员）有其他任务在身，不能在客户现场开发。迫不得已，安排他们在广州开发一
期，项目组主力驻客户现场开发二期，分为两条开发主线并行开发。当时错误的估算了一期
的工作量和高估了广州开发人员的能力，在 Week1 结束后（7 月 15 日）发现广州开发小组
只是做了几个还没有完善的 jsp 页面，其他什么都没有，进度已经严重滞后。当时分析的原
实践 健康 创新 家园

33. 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 的
代码复审等等，质量可想而知了。不过我们都挺过去了：一切终须过去，只要奋起面对。
相比较而言，二期的质量就好多了，毕竟是项目组的主力完成。二期的开发是跟一期同
实践 健康 创新 家园

34. 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 可比拟的。
实践 健康 创新 家园

35. 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 的新片《世界之战》 月 3 日奋战了一天，直到晚上 9:30 才从 X 地回广州，在东
。9
圃的农家庄吃饭，东西还不错，就是吃得太晚了，到家已经是凌晨了，感觉，真累。
9 月 5 日，一个值得回忆的日子，在没有延期的情况下，系统如期上线。辛苦了整整两
个月，总算有所回报。
实践 健康 创新 家园

36. PM 成长
我与项目管理
文 / 蓝叶菱
实践才是重要的。知识的名词，知识，书籍的膨胀会让你感到
无奈，你有本事把书读薄，那个叫本事，越读名词越多，知识越多，
估计你这辈子都不会有尽头。 知识有界，智慧无界。
很早以前的故事----我不知道项目管理如何做项目管理？
就在五六年前，还是六七年前，自己还是一个公司的技术部门经理的时候，头衔很虚，
部门的兵很少，准确的讲就是道道地地的程序员，高级都谈不上，至少在部门的那些兵里面
算高手了。
由于我们单位的带有政府性质特殊背景，我居然有幸承担过 2000 多万的项目，一期工
程的硬件投入大约 800 万，纯软件的开发约 600 多万（实际到账不足 400 万）
，结果就是这
样，我啥都不懂，领导问我可以不可以搞？当时年轻，怕什么，不就是软件开发吗？什么硬
件部署吗？我告诉头说：小 CASE。当时我脑子里面啥项目管理的概念都没有，就这样，我
们承接了项目。
当时，我们编写硬件的方案，和网络公司合作编写方案，没有干过，百度帮忙，我和客
户的老哥很熟，他也是客户方的负责人，就这样我们就完成了方案，软件开发只有初步的概
要方案的稿子，需求调研，和客户一点一点的边开发边完善，客户（现在是客户部门的这些
职员都是我的朋友了）和我一起工作，当时工资不高，客户请客，饭吃的不错，至少我这个
穷人吃的胖了不少，什么加班，我们怀着打造全国最好的系统的思想，都在不断地努力着。
就是这样 1 年半，三大软件研发先后完成。其中一个中型业务系统消耗的时间达到 8
个月。
我非常投入，我身体垮了。项目在实施的时候，遭遇到部分用户的抵制，这些用户从来
没有摸过电脑，我们的系统包含财务系统，这就意味着政府单位的很多人的可观的灰 Se 收
入被剥夺了， 但是高级领导层授权， 就这样面对着都不知道什么是任意键的超级可爱的挑剔
用户，运行 1 年多，终于的到了客户的肯定。
这个项目当时同类的有北京的某上市公司做过，结果和我们的相比，根本不贴近客户现
实而被说成了垃圾。
后来，单位被政府收编，二期工程中的中型业务被另外一个公司被承包了，那个单位从
开发到最后上线，照着我们开发的样板，带领比我们多的团队进行二次开发，漂亮的需求分
析文档，居然研发了 1 年半多。
这个项目我们创造了神话，这个项目中我根本啥都不知道，不懂啥叫项目管理。可是在
这个项目中，我知道我的项目研发也没有达到极限，一直在思考自己哪些环节还能做的更好，
后来才开始接触软件工程、企业管理、项目管理。
为什么这个项目成功？第一：亮剑精神；第二：为了我们的目标，不断地排除障碍， （后
来学习 PM，才知道那个叫风险管理）
，第三：做好客户参与，没有写过需求文档， （后来知
道用了很多敏捷开发中极限编程的关键实践）。第四：不会的问题，CSDN,百度帮忙，一种破
实践 健康 创新 家园

37. PM 成长
除各种难关的精神。
当然，还有很多敏捷的，这里不提也罢， 有成功的也有失败的，不过当时不懂啥叫 AP；
有失败的地方没有，当然有，就因为有失败的才让我后来学习和提高，开始思考怎么让
技术为企业服务，学习企业管理？
但是最后我失败了，失败的是，我的身体垮了，这个是最大的失败。
项目管理不是神秘得遥不可及。现在学习了项目管理，考取了 XXX 证，其实就是为了
工作，现在做的不如以前，因为我现在更多的是思考，失败的自己。毕竟那个不叫人生，人
生要量力而行。
风险管理是项目管理的最重要的核心之一。
现在来北京了，没有以前的热情，现在面对项目就是在思考，如何达到某种极限而已。
对于大项目也没有热情。
我面对的是成为职业项目经理人的思维转变的问题，不可否认我的思维停留在技术思维
里面。
6 年-7 年前，计算机语言还在讨论那个好?那个坏?架构还不知道走向何方，软件工程的
词还没有来到中国。
至少在中国中小企业里，CMMI 很多企业还在琢磨是个啥东西。
以上的例子，千万不要有错觉，只是告诉你项目管理是大众学科，没什么神秘高深可言。
和中国五千年的智慧，不值一提。甚至都不如买菜的企业家。有点谢永强回到象牙山的尴尬。
实践才是重要的。知识的名词，知识，书籍的膨胀会让你感到无奈，你有本事把书读薄，
那个叫本事，越读名词越多，知识越多，估计你这辈子都不会有尽头。 知识有界，智慧无
界。
当然，以上不是告诉你说项目管理知识无用，至少告诉你实践更加有用而已，学习是必
须的，但是思考和实践更是必须的而已。
切记，切记„„我从来不说项目管理，但是还是喜欢看。
实践 健康 创新 家园