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