[
周例会制度是本文推荐最有可行性的软件开发管理手段。每周用1-1.5小时左右，每个人简要汇报本周工作和下周计划的工作，工作中的问题和难点，这时，他会得到整个项目组的建议和帮助；项目经理可以印证了解到的项目进展情况；团队气氛由此加强。如果还有很多富余的时间，项目组可以讨论一下开发技术、技巧，进行一些技术交流。
总之，沟通不足是软件开发中很大的问题，而且越是大项目就越严重。
8、 约定开发纪律、规范
没有规矩，不成方圆。项目组一定要有一些纪律，不能完全依靠自律。
这方面，有公司文化、氛围积淀为基础是最好，否则就应该制订一些规矩了。
这也是保持团队的重要组成部分。
至于开发规范，根据项目不同而有所不同，要点是：必须有，哪怕不完美！
而且，应该开诚布公，尽早公示。
9、 风险估计和预备应对计划
风险估计应该每个阶段都进行一次，一般是根据风险列表，大家一起来估计。
其实也是让大家充分认识到项目的处境和潜在的困难。
这件事，做了总比不做好。
10、 CCB评审项目计划
项目计划必须得到CCB会议形式的认可，否则一定会有问题！
设计阶段
1、 周期性内部评审和走查
在这个阶段，周期性内部评审和走查的目的更多是为了交流，检查模块间是否能够协作、是否有矛盾和遗漏，作为平时非正式沟通的一个强有力的补充，大家取长补短，集思广益，几个人的脑袋总比一个脑袋强；第二个目的是质量控制。第三个目的才是控制进度。
根据上述特点，评审自然应该采用会议方式，也许会有人觉得冗长、拖沓，浪费了一些人不必要的时间；但是该方式的效费比非常好，是值得的；至于组织会议的人，一般是项目经理，应该多动脑子，调动大家的积极性。有人会提出使用checklist的方式，本人的经验是：该方式削弱了沟通量，而且需要良好的制度的支持，否则容易走形式。
2、 项目跟踪
项目计划制订后，项目跟踪工作就要开始了。跟踪表应该每周填写，这样项目中的问题会被及时发现；而且最好不要用project跟踪，而是自己制作一张或寻找合适的软件。一般是根据项目计划制订，有下列内容：任务包，计划的规模、工作量、进度，实际的规模、工作量、进度，二者的误差以及原因分析。
任务包完成的百分比应该如何填？本人的标准是：如果只是听成员汇报，没有100%完成的都是0%，是0-100原则；听了成员汇报，自己简单察看过工作产品的，是0-50-100原则；仔细检查过的，可以参照成员的汇报，按0-25-50-75-100原则填写。如果一个5工作日的工作包，上边写着完成43%，那是一点意义也没有的。
项目跟踪的结果用于分析项目进展情况，里程碑报告，务必真实。
3、 变更控制
变更控制的具体手段请参照需求阶段的原则。在本阶段，一般只是开发人员发现需求不合理，或相互设计矛盾而要求变更。一些非基线变更的控制不需要那么严格，意思是不需要CCB评审，但项目经理要根据实际情况决定是否召集项目组内相关人员的评审。
同时，应该在这个阶段让大家养成遵守变更规定的习惯。
编码阶段
1、 重新进行工作估计，有必要时修订计划
进入到编码阶段，对项目的认识已经非常清晰了。根据设计，甚至可以计算出未来的代码行数。重新进行工作估计，可以更好地分配人员到合适各人技术特点和兴趣的方面，提高项目组的积极性；同时，可以使管理层清晰认识到项目进展的真实情况，做出正确的决定或避免他们做出错误的决定。
2、 标准制订和培训
编码的标准在现在已经逐渐趋向统一，但是仍然有必要在项目组中推行或制订编码标准。
统一的编码标准，可以使项目组内可以容易地互相协助、交流，为走查、测试等工作奠定良好的基础。
编码标准制订后，首先要进行项目组内培训。不过与其说是培训，不如说是讨论和统一认识，建立未来强制执行和检查的前提。（不教而诛谓为虐，教而后诛谓为化）
3、 周期性走查
根据经验和一些统计数字，走查的效果要优于测试。[本文共有 3 页，当前是第 2 页] <<上一页 下一页>> ]
|
|
|
|
|
|
|
您的位置：
