|
2、 标准制订和培训
编码的标准在现在已经逐渐趋向统一，但是仍然有必要在项目组中推行或制订编码标准。项目管理者联盟 统一的编码标准，可以使项目组内可以容易地互相协助、交流，为走查、测试等工作奠定良好的基础。项目管理者联盟 编码标准制订后，首先要进行项目组内培训。不过与其说是培训，不如说是讨论和统一认识，建立未来强制执行和检查的前提。（不教而诛谓为虐，教而后诛谓为化）PgMp.mypm.net 3、 周期性走查
根据经验和一些统计数字，走查的效果要优于测试。项目管理者联盟 走查要以统一的编码标准为基础，反过来，统一的编码标准也是通过走查而在项目组中建立起来的。本人的经验是：开始时，安排每周2次走查，每次1小时，只检查一个人的一个功能，重点是编码标准，其次是BUG；大家可以通过走查学习他人的优良风格，改正自己的不足；两周后整个项目组基本上风格就统一了，这之后就应该把重点放在程序功能上，其次是BUG。项目管理者联盟 4、 周创建或日创建项目管理者联盟 5、 项目跟踪
项目跟踪在本阶段较容易，因为量化的东西比较多，虚的东西比较少。基本方法与上个阶段相同。通过跟踪，已经可以看出那些模块在上个阶段没有设计好。项目管理者联盟 跟踪要有分析，分析有了结果要有行动。项目管理者联盟 6、 变更控制
在这个阶段，一般是开发人员在实现时发现一些设计错误而要求变更；这时，就要求项目经理严格把关，与设计人员、开发人员一起研究是否真的需要变更，还是实现者没有领会设计者的意图。如果需要变更，则要谨慎地研究影响范围，评估损失。项目管理者联盟 在这个阶段的中、后期，随着部分产品逐渐成形，客户会提出变更要求；此时要注意原则，同时要搞好关系，当然，首先是原则—CCB同意。项目管理者联盟 7、 版本控制
事实上，版本控制在项目一开始时就应该展开，但未必所有的项目组都能够做到，能做好的就更加寥寥无几了。但在编码阶段，则最好要进行版本控制了，良好的控制机制可以减少很多无用功，甚至避免一些灾难。转自项目管理者联盟 良好的版本控制不是来自好的版本控制工具软件，而是版本变更控制的制度以及因此形成的良好习惯。建立一个成文的规定或规范并保证它的实行，才能使版本控制不流于形式。 如果进行了版本控制，则建议推行MISRA Rule 10-- 不得残留被注释掉的废代码。项目管理者联盟 常用的版本控制工具有VSS,CVS,rational套件中的clearcase也很好，只是会用会配置的人不多；UNIX下开发时，它自带的SCCS也是很好用的。项目管理者联盟 测试阶段
1、 制订返工标准和重申纪律
一个糟糕的程序总是会不断地被要求修改，测试工作大部分是由少数几个程序或个别程序员完成的程序引起的。不断地修改的产品无论改多少次都不会变成好产品。项目经理圈子 因此，应该制订程序返工标准，一个可以参照的值是15BUG/1000Line。达到了这个标准，直接删除该程序，要求程序员重写；新程序再次达到这个标准时，就换人。而且，应该严格执行这条规定—前提是：该规定在编码阶段就通知了大家。项目管理者联盟 2、 日创建
测试阶段的日创建简直是被迫进行的，特别是在初期；否则测试简直进行不下去。blog.mypm.net 但是注意不要丧失原则，为了赶进度破坏了版本控制。club.mypm.net 3、 变更控制
测试阶段是客户提出变更最多的时候，注意不要丧失原则，要坚持CCB评审。必要的变更是必须进行的，但是要仔细评估其影响。匆匆进行的变更既破坏了规矩，也往往破坏了产品。记住一句名言：如果厨师做菜的时间长了，那是因为他想把菜做的更好。项目经理圈子 4、 版本控制
如果在这个阶段没有一个良好的版本控制行动的话，测试工作一定会有一种混乱的感觉；而且，这是日创建的前提。training.mypm.net 5、 项目跟踪
项目跟踪在这个阶段是最困难的。因为事情往往琐碎而且交织在一起。项目经理既当裁判，又作记分员，还要是教练、队长，必要时还要亲自上阵。一个好的产品，在测试阶段一定不会一团糟的。项目管理者联盟 但是，需要坚持项目跟踪；积累这个阶段的数据，才能真正评价项目、项目组每个成员、项目采用的技术（包括管理技术）优点和缺点，为公司、个人积累起经验。所以，虽然这个时候项目经理很忙、很累、有很多重要的事情要处理，但还是应该坚持项目跟踪。项目管理者联盟 项目收尾
项目收尾时应该进行项目总结，主要是评价项目产品、采用的技术、管理方法、优势、缺点和项目组每个成员。项目管理者联盟 通过项目跟踪获得的数据可以作为评价的基础，但是不能做量化的评定（分级或者打分），只能是定性的评价—一个尽量详尽的文字说明。总结的目的是面向未来的新项目，而不是惩戒某些人，定量的评价对于下一个全新的任务基本上没有任何帮助。PgMp.mypm.net 如何能够正确地评价和使用人，依然是一个管理学难题。项目管理者联盟
|
