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