2004项目管理半年总结
原创作者：luxc
转载请注明：来自Sawin系统分析之窗
最后修改时间：2005-3-22
1 引言
时光飞逝，又是一个半年过去。回顾2004年上半年的工作，仿佛历历在目。通过XXX版本的研发，感慨甚多。相比较而言，今年的研发及管理工作，相对去年的930版本，有很大提高，在此，就项目中运用到的各种方式方法作一下小结，以期达到共勉的效果，同时总结过去，继往开来，为下半年的研发做一些基础性的工作。office:office" />
2 项目管理总结
2.1 严格控制需求
首先，需求必须经过充分讨论，明确哪些该做，哪些不该做；评判一个需求是否做的基本标准，应该是客户说了算。对于我们项目而言，我们主要是针对用服部的意见和部分客户的意见，只要是他们认为需要做的功能，即使再难也要做！
其次，某个版本的需求一旦确定，就不得更改（当然绝对了些，特殊情况出外）；不更改需求的原因很简单：因为需求的变更，将带来一系列的问题，比如设计问题，实现问题，新故障引入问题等等，将严重影响项目计划的执行；
第三：需求必须每一个研发、测试人员都参与，要求每一个人都做到心中有数；即这个版本，我们需要做些什么，大致做成什么样子。
收集需求是非常重要的，好在现在事业部有专门的原始需求库。当然，单单只依靠原始需求库是不够的，还需要项目组在平时的工作中，进行工程问题的收集，这样才能够做好整套版本的需求工作。
2.2 一定要做估算
尽管，目前我们的估算水平有限，但是，估算还是一定要做的。只有建立在估算基础上的计划，才是有点准确的计划，如果没有经过估算，只是几个人拍拍脑袋定出来的计划，肯定是不行的，100％延期。
有人说：即使你估算做的再好，最后还是领导说什么时间就是什么时间，我认为其实不然。对于我们这种公司，我们这种产品，一切都以市场为导向，因为领导如此决策，也是不得已而为之，毕竟也都是为了我们的产品在市场上多多销售，多多赚钱。因此，项目管理而言，无论上级领导指示什么时间，项目管理者必须清楚的认识到，完成本项目要求，需要什么时间才能够完成。
通过估算，也才能够跟领导交流，也才能够有根有据的去跟领导交流，也才能够争取到时间资源、人力资源等等；
没有估算的计划，是无效的计划，是空头支票。
估算方法非常多，从我们项目应用情况看，建议大家都按照1－4－1的原则进行估算，还比较准确。
2.3 同行评审是利器，可是应用得比较差
同行评审，在CMM中，拥有很高的地位，为什么呢？
因为经过同行评审，可以：
1、 最大限度的发现了故障，使得故障在初期发现；
2、 使得单元/模块/子系统熟悉的人员更多，能够增加项目抗风险的能力；
我们目前还存在的缺点：
1、 同行评审还没有严格的计划性；
2、 预审时间不足，预审不充分，即使在预审时间充足的情况下，预审也不是很好；
3、 预审时没有很好的使用检查单；
4、 思想观念还未转换，认为这是别人的事情，跟自己不怎么相关，大致看一下即可，导致预审效果较差；
5、 同行评审会议条件未严格执行，不能够召开的同行评审，也照样在进行；
6、 同行评审会议组织上还存在一些问题，比如长篇文档，应该拆分的没有拆分等；
7、 同行评审流程在notes上部分没有严格执行；
8、 同行评审的记录员做得非常差；
9、 同行评审的结果修改，还存在少数的跟踪力度差；
2.4 集成测试必须加强
总体来看，今年上半年，在集成测试方面，我们做的很不够，只是比去年好一些而已。集成测试非常重要，是减少产品故障非常有效的手段。事业部也非常重视单元测试和集成测试；加强集成测试的理由很简单：就是为了避免故障流入系统测试阶段，减少研发故障，同时减少测试部测试的次数，提高了效率；另外很重要的一点就是：测试部测试的次数减少了，增加了研发人员对版本的信心，有助于提升战斗力。
2.5 工作安排调整
根据目前研发的实际情况，今年在研发中的工作安排，做了如下调整：
1、 详细设计过程中，测试人员基本都参与其中，当然还需要更进一步加强；
2、 编码及自测时间相对拉长，重心逐步开始前移；
3、 每次系统测试，指定专门的测试接口人；
4、 每次系统测试前，基本都进行集成版本自测，以后还需要加强；
5、 每次系统测试期间，研发人员先不分析测试故障，而是进行专项走查或者是集成测试；
6、 测试周期拉长，测试次数减少，加强了自测力度；
2.6 项目管理与风险
2.6.1 风险管理
有人说：项目管理就是风险管理！
这句话非常实在，我认为这应该是项目管理的核心思想。同时，项目管理过程，也就是与风险作斗争的过程。
对于软件项目，按照我们目前的设计水平，前面的阶段，看起来都非常顺利，一直可以顺利到对内交付测试。然而，一旦提交测试部测试后，故障一堆一堆接踵而至（是什么原因呢，当然是前面阶段控制不好，输出产品质量差导致的）。
项目实际管理过程中的不得不注意的风险：
1、 重大测试故障，无法定位解决，故障表征为时而出现，时而消失；
2、 隐藏的重大故障，有可能几次测试都不出来，最后一次计划测试通过时出现，甚至测试中不出来，工程开局才出来；
3、 需求变更：在版本研发过程中，尽管前期已经进行了多次的需求讨论，但是实际上，总会有新的需求出现，应该视需求的重要程度，尽量不修改原来已定的版本需求，否则，必须进行重新的估算，并调整计划；
4、 工程应急和人力变动的影响：
2.6.2 专项走查
扼杀隐藏故障非常有效的手段！
代码走查，一直是解决疑难杂症的最常用手段。但是，一般而言，走查代码花费的代价是非常昂贵的。业界比较公认的：任何故障，每经过一个阶段，其解决难度和时间将放大10倍乃至更大；比如一个故障如果在设计时产生，如果详设没有识别出来，在编码才识别，则该故障的解决花费的时间将是设计时解决的10倍；如果编码时间也未能够发现，则在测试时花费的时间将是设计时解决的100倍。
为了有效的控制隐藏故障，进行有意识的活动，是必不可少的。应该说这是防患于未然的一种吧。
今年上半年，项目在管理过程中，有意识的进行了代码的专项走查工作。之所以叫做专项走查，是因为跟一般的代码走查不一样。我们安排研发人员有专门的目的性走查，比如：对某个模块的memcpy函数保护的走查，对数据库操作必须关闭记录集的走查等等。
总结专项走查，有如下要点：
1、 专项走查是一项长期的工作，不能够急于求成；
2、 专项走查一定要按模块进行，并根据模块不同制定不同的专项走查；
3、 走查一定要出走查报告；
4、 走查结果需要严格同行评审后才能够修改代码；
5、 切记整个版本进行大面积修改某一个专项走查的故障；因为修改故障非常容易新故障；
6、 修改后一定要做代码对比检查；并结合走查报告，核对修改是否正确；
实践证明，我们开展的专项走查非常有效，将在我们项目长期坚持！
2.6.3 工具的使用
公欲善其事，必先利其器！
通过半年的实践应用，在已经使用的8中工具中，值得推广使用的有三种工具：
1、 pclint，该工具属于静态检查工具类，是代码编写质量好坏的一个重要检查工具；能够发现很多的隐藏故障，非常好用，也是业界推崇的工具之一；建议本工具在编码阶段和走查代码时使用；
2、 coverage，该工具数据动态检查工具类，是检查测试覆盖的重要工具，能够加强自测力度；建议本工具在单元测试和集成测试阶段使用；
3、 windows 程序reease版本的定位调试工具，该工具数据跟踪调试类，必须要故障再次出现，才能够定位到代码行，并且需要跟编译时的pdb文件配套才能够使用；建议本工具在系统测试阶段使用；
其余工具不再赘述。
2.7 要点小结
1、 需求控制更加严格，不能够轻易进行需求变更，哪怕是简单到只修改一个汉字的显示；
2、 计划必须建立在估算之上，即使领导要求的日期跟估算不符合，也应该进行估算，做到心中有数；
3、 任何工作产品，都应该做同行评审；即使是代码，也建议要抽重点模块做同行评审；
4、 单元测试之后，集成测试必不可少，同时应该加大集成测试的力度；加强集成测试，控制系统测试频次，因为无休止的测试导致战斗力丧失；
5、 充分利用系统测试阶段的人力资源，不要将人力资源都花在测试部测试出来的故障上；
6、 整个项目管理过程中，都要有风险意识，时刻并尽可能多的识别风险，想办法规避风险；
7、 充分利用工具，公欲善其事，必先利其器！
8、 逐步实现时间前移，研发重心开始由测试逐步转移至设计阶段；这是一个漫长的过程，国外用了将近20年的时间才走完这段路程，我们也不能够急于求成。
3 最终目标
3.1 改进与展望
回顾过去，展望未来，改变现实，促进发展：
1、 研发时间逐步前移，压力逐步前移：即在项目计划过程中，有意识的将需求、方案、详设、编码、自测阶段的时间安排多一些，后续系统测试等时间安排少一点，将压力从系统测试阶段逐步前移。要是有一天，我们能够实现让初中生来编码，我们只进行设计，那我们就成功了；
2、 方案及详设严格控制：从目前的管理来看，在方案阶段和详细设计阶段，其输出产品的验收工作做的非常不够，我们的许许多多的缺陷，都是在这一阶段引入的。
3、 有故障在所难免，但是故障的波及范围分析一定要到位：
4、 质量虽然不是测试出来的，但是测试功不可没，因此一定要想办法提高测试质量：这里的测试主要指测试部的系统测试，如何提高测试质量，使得泄漏率降低，使得故障全部被测试出来，是摆在我们面前的重要课题，项目组下半年计划在这方面做一些研究；
5、 项目成员观念的转变培养：人的观念至关重要，观念决定行为，行为决定成就；项目管理有责任也有义务培养大家：比如主动式工作的习惯，质量观念、软件研发设计如何重要等观念转变………
3.2 最终目标
质量是设计出来的，不是测试出来的！
我们一定要转变这个观念，不要把质量认为是测试部的事情！
观念的转变，才能够指引行为的转变；行为的转变，才能够带来更大的成就！
最后，希望每一位员工，都能够进行反思。每一个版本，我们没有增加多少功能，没有修改多少故障，却搞出来那么那么多的故障。就拿XXX版本而言，需求就那么多，结果却搞出来500多个故障，研发人员自己测试的人员还不算，这些故障是怎么来的呢！是从详细设计就开始引入了，考虑不全面，不周到，波及影响分析不够等等，真正编码引入的故障，不到30%，因此，希望大家都注重设计，注重评审。
4 附录
4.1 简要对比2003年项目管理及2004年项目管理情况
序号
对比主题
2003年（930版本）
2004年（XXX版本）
备注
1.
需求
有重大需求的增加
基本无需求变更
2.
总体进度
不断调整，最后延期将近三个月才测试通过
按照计划测试通过
3.
同行评审
执行比较随便，不严格
比较严格的执行了同行评审
4.
计划
无总体计划，时间终点明确，但中间缺乏计划
年初就制定了半年计划，非常明确
5.
研发工具
未使用
使用部分工具
这里不是指CC/CQ等工具
6.
估算
虽然进行，但形同虚设
进行，效果较好
7.
风险意识
有，但是防范工作做的不好
有，防范工作做的较好
8.
集成测试
未专门安排
有专门安排
9.
全员对目标和计划的了解和把握
不了解
了解，并通报进展情况
4.2 防止项目延迟的18条准则
这都是前人的血泪写就的，再次回味，希望每一个人都有所收获。
====================================================
1 详尽的需求分析。
2 项目面临问题时，您需要正视并处理这些困难和有争议的问题而不应该逃避。
3 选择正确的技术
正确的技术能够使您有最大的机会在现有的人力条件下以最短时间按质量要求完成工作，选择一个抢眼的新技术并没有什么好处，尤其当您不能保证它是否有好处或者找不到正确应用新技术的人的时候。
4 设计一个产品的体系结构，这个结构要有很好的模块化特性，并且简单易懂。要花时间在设计功能模块和界面上，并且对这些模块和界面进行封装和组织
5 一旦您知道了您将需要做些什么，您就可以立即着手准备计划，然后不断细化。
6 不断回顾和项目相关的标书，合同和其他高层文件。
如果您的计划表明合同得不到执行，那么为了避免以后的严重问题就必须进行重新谈判。
7 评审设计和代码，越早发现问题越好，测试是昂贵的。
8 确定优先次序
a.)确保首先将精力放在最紧急的事情，其次是最重要的事情，如果还有余下的时间再去做不太重要的事情。重要的是从客户角度考察事情的优先次序。
b.) 确保问题得到充分的解决。
9 处理需求的变化
不管变化如何小，您都要进行必要的处理，将这种变化的结果反馈给客户或者市场部门。不要期望在没有更多时间和资源的情况下做更多的事情。
10 让人们努力并机智地工作是问题的关键。
用时间和功能命名交付的产品要比仅仅使用数字命名更好。
您应该相信团队成员，相信他们明白需要做什么，并且会全力以赴做好它。
11 减少风险
a.)不要仅仅为了使用新的技术语言或者方法而使用它们。
b.)尽量避免不同的语言或技术混用。
C.)减少对其他项目和组织的依赖性
d.)在项目计划中要包含充分的权变措施。
项目延迟常常是由于一些主要的风险因素，例如新技术的失败或供应方延迟提交产品。
12 不做无用功。重用，重用，还是重用！
13 采用稳固的编程方式
a.)在开发工具中应用最高级的警告功能。
b.)应用错误检查工具来发现内存泄露，通用代码错误和其他潜在缺陷。
c.)养成在写完程序之后立即测试的习惯。
d.)记下测试出的程序错误并编写报告。
e.)使用可靠的结构和算法。
14 减少“设计-编程-测试”循环的时间长度――合理的版本规划。
15 测试开展得越早越好，且不要在此过于吝惜投入。
16 定期进行产品发布。
您得到的反馈越多您的客户最后拒绝您的产品的可能性就越小。
17 为了防止您的项目延迟，您必须承担领导的责任，进行切实的领导。
a.)担负起责任，不责备他人，不找借口，勇于承认错误并改进。
b.)不要任由他人责备，也不要寻找不具说话力的借口。
c.)为了整个项目团队能顺利工作，您必须做一些领导应该做的事情，即使这些事情并不让人惬意。
d.)如果您知道问题所在就立刻着手解决这些问题而不要无视问题的存在。
e.)要做全局把握整个项目的人。
18 为了节省时间一定要舍得花时间。
如果您有方法能够为整个项目节省时间，那么就采用这种方法,尽管它可能会使工作暂时落后于预定计划。
【作者介绍】 luxc
卢西昌，资深软件专家，目前在某大型企业负责测试管理。
作者Email地址：luxichang@cpichq.com.cn
