前言
为更好地开发软件，必须在项目组中引入一些软件工程手段和方法。本文试讨论了无论公司情况如何，一个项目经理都应该可以在项目组中实行的一些手段和方法；当然，公司情况良好则有更加可行的、更多的方法可以选择；这里只讨论了最差情况下可以采用的方法。
本文按照最简单的瀑布模式的各个阶段分别列举了一些方法，在其他模式中应该也可以采用。
需求阶段
需求的管理应该是贯穿整个开发过程。在这个阶段，可以采用的方法有：
1、CCB(变更控制委员会)
建立CCB（change control board）是需求管理的前提，否则需求管理将成为一句空话。
CCB必须包含客户方的决策人士，项目经理，项目经理的领导，关键设计人员，测试负责人，SQA.等，以5-7人左右为宜。
需求确认，发生变更等活动必须由CCB以会议形式批准。
CCB对整个项目有最高权力（不仅负责需求变更，还负责听取项目经理汇报、关键中间工作产品评审等重要决策）
2、 需求评审，纳入基线
原始需求必须形成文档，被CCB评审，然后纳入基线管理，所有变更都需要CCB评审。
该评审一般步骤：
（1）. 项目经理提出被评审对象，指出受影响、被牵涉对象，评估影响（主要是带来的规模、工作量、成本），提出计划和计划执行人，举出可能风险；
（2）. CCB来决定是否同意或要求项目经理修改上述项；
（3）. 之后，项目经理提交执行情况汇报。
（4）. 最后，CCB指定代表或由SQA进行核实。
如果变更过小，过多，可以进行周汇总评审。
项目计划阶段
项目计划是开发的指导或脚本，事实上，在每一个阶段开始时，都应该重新、小范围修订一下计划。
1、 选择合适的软件开发生命周期
关于生命周期的选择上，一直有而且会有很多争议。目前，国内运用最多的是纯瀑布生命周期；本人的看法是：一定有更好的选择，但这是一个最安全、最少在实际中有争议的选择。
选择合适的生命周期的要点是：一定要有选择原因的陈述—本项目的特点，团队特点，开发特点和公司或部门的特点；该问题必须事先在项目组中、CCB内被讨论过并得到一定认可。
2、 划分阶段--小里程碑
根据选定的生命周期模型，考虑到可以投入的人员，各个开发阶段就呼之欲出了。每个阶段的结束一定是一个里程碑。如果里程碑超过一个月，那么应该在每经过一个月左右选择合适的点作为小里程碑。
每达到一个里程碑时，项目经理应该提交本阶段工作报告，一般应该包括：
（1）. 本阶段活动统计和估计的数值和它们差异的原因
（2）. 工作产品完成情况
（3）. 需求变更情况统计
（4）. 问题及其解决情况的统计
（5）. 总结优点和缺点，指出对下一步工作的影响
CCB听取该报告并评价该阶段工作。
小里程碑可以防止项目失控，使项目经理、项目组和其上的管理层能够正确认识到项目进展情况，并能协助项目开展、出谋划策，项目可视化好；避免项目发生大问题。
3、 决定工作产品和含中间工作产品
在最混乱的项目中，工作产品和中间工作产品都没有被明确定义，或者可以朝令夕改，随意添加或去除产品。决定工作产品和中间工作产品，是为了确定各个产品的重要性，计算其上的工作量以合理地投入足够的、合适人员来开发它。
4、 项目工作分解
一般是将系统分解成模块甚至更细，要分多细由项目经理或分析员根据实际对项目产品的认识和人力、进度的压力而定；一个忠告：开始做的细、做的认真，以后的工作都会相应容易很多。
一般人只分解产品。实际上，管理工作也应该分解的，而且也比较容易作。
5、 估计
估计常常被忽略掉，因为估计的结果往往会严重超出预算，让人大吃一惊。而到了最后，结果又往往接近当初估计的数字。
估计应该每个阶段作为更新计划的一部分进行一次，每个新的估计都会更加准确。
估计应该选取有经验的人士参与，应该选择合适的方法
估计的结果应该用于指导编制下一阶段的计划，即使不被正式接受，项目组也不应该忘记这些数字，时刻作为参照。
6、 明确职责—团队建设
根据项目特点和人员特点，应该选择合适的模式来组建团队进行开发，每个人都应该有明确的责任和工作。
最低限度，每个人都应该有明确的责任和工作。
7、 约定沟通方式、渠道
建立沟通渠道这一条可以不成文，但要成规矩。沟通渠道应该开放，畅通。为每个人指定汇报的领导、汇报的周期、汇报的方式和越级汇报的领导、条件和方式。
建议在项目中开展项目日志，周报制度，具体的方式方法可以参考PSP,TSP。该制度的要点是：日志首先是对自己负责，不能作为评价员工的依据，它是属于成员“开放的隐私“。如果要求每天填满8小时工作，这样的日志没有任何意义；事实上，在本人的项目组中，根据日志，一般没有人每周投入工作的时间超过35小时，平均只有28小时左右—当然，你依然可以看到他们每天都很忙碌的样子，有时还有加班呢。[本文共有 3 页，当前是第 1 页] <<上一页 下一页>>
|
|
|
|
|
|
|
您的位置：
