IT项目管理-计划-进度计划的关注点.doc

IT 项目管理 -计划 -进度计划的关注点 WBS 确定后项目详细范围基本确定，在 PMBOK 的时间管理里面有详细的进度计划制定步骤。活动定义 ->活动排序 ->估算资源 ->估算历时 ->制定进度表，同时也提及到了估算方法，关键路径， PERT 网络，关键链，资源平衡等重要内容。但在整个过程中有太多的假设，假设创建出来的是理想化的进度表，而我们需要的是可行的进度表。 1.进度计划不要去追求理论最优，而应该考虑可行性和对目标的满足。 2.在活动定义和排序估算中都可能会发现 WBS 分解层次，粒度，遗漏等问题 3.PMBOK 中制定进度各步骤并没有严格的先后关系 ,IT 项目强调关键点是 WBS,估算有后即可制定进度。 项目进度安排的首要目标 :在满足质量和成本要求的情况下，满足项目预期的进度要求。因此从这个目标 出发需要优先考虑两个问题，一个就是软件生命周期和方法论的选择，一个就是团队组建，人员的搭配和角色安排。而这两个问题都是基于一个目的，或者说是基于 TOC 约束理论的思路，不要在项目执行过程中因为瓶颈存在使过多的人员闲置和等待，而是要达到人力资源最佳配置和最有效的利用。 4.制定进度前往往就已经想好了开发方法论选择和人员角色搭配安排。 5.瓶颈造成资源利用不均和等待，进度安排中资源利用最大化是 TOC 一个重要体现。 6.在生产管理中一般在瓶颈资源前预留缓冲，而在关键链中是要考虑在路径汇聚点 (最大风险处 )前预留缓冲。 7.小型敏捷团队，整个计划中如果出现前期资源不饱和和空闲是要命的事情。 瀑布，迭代还是敏捷开发？关键需要解决的还是最大化的降低后续工序资源的等待时间。对于中小型短周期的项目一般适合采用迭代或敏捷的开发方法。但敏捷不是跳过程，敏捷或迭代最好是基于前期整个开发模式和功能框架都已经确定后再进行，这里指的并行是多个需求功能点的并行，对有严格依赖关系的，对同一个功能点的需求，设计，编码多道工序而言仍然是串行。 8.任何方法论都不会是跳过程，而是将大瀑布转换为小瀑布。 9.并行和敏捷后势必影响到总体规划和系统思考，务 必重视带来的需求不清和架构风险。 网络图是进度中的一个重要工具，目的仍然是对发掘各活动任务的依赖关系并对活动进行排序。在软件项目中为了加强迭代和并行，一个重点就是要将强制依赖转换为非强制依赖，要将对整个设计开发过程的依赖转换为对接口的依赖