WBS确定后项目详细范围基本确定，在PMBOK的时间管理里面有详细的进度计 划制定步骤。活动定义->活动排序->估算资源->估算历时->制定进度表，同时也提及到了估算方法，关键路径，PERT网络， 关键链，资源平衡等重要内容。但在整个过程中有太多的假设，假设创建出来的是理想化的进度表，而我们需要的是可行的进度表。

    1.进度计划不要去追求理论最优，而应该考虑可行性和对目标的满足。

    2.在活动定义和排序估算中都可能会发现WBS分解层次，粒度，遗漏等问题。

    3.PMBOK中制定进度各步骤并没有严格的先后关系,IT项目强调关键点是WBS,估算有后即可制定进度。

    项目进度安排的首要目标:在满足质量和成本要求的情况下，满足项目预期的进度要求。因此从这个目标出发需要优先考虑两个问题，一个就是软件生命周期和方法论的选择，一个就是团队组建，人员的搭配和角色安排。而这两个问题都是基于一个 目的，或者说是基于TOC约束理论的思路，不要在项目执行过程中因为瓶颈存在使过多的人员闲置和等待，而是要达到人力资源最佳配置和最有效的利用。

    4.制定进度前往往就已经想好了开发方法论选择和人员角色搭配安排。

    5.瓶颈造成资源利用不均和等待，进度安排中资源利用最大化是TOC一个重要体现。

    6.在生产管理中一般在瓶颈资源前预留缓冲，而在关键链中是要考虑在路径汇聚点(最大风险处)前预留缓冲。

    7.小型敏捷团队，整个计划中如果出现前期资源不饱和和空闲是要命的事情。

    瀑布，迭代还是敏捷开发？关键需要解决的还是最大化的降低后续工序资源的等待时间。对于中小型短周期的项目一般适合采用迭代或敏捷的开发方法。但敏捷不是跳过程，敏捷或迭代最好是基于前期整个开发模式和功能框架都已经确定后再进行，这里指的并行是多个需求功能点的并行，对有严格依赖关系的，对同一个功能点的需求，设计，编码多道工序而言仍然是串行。

    8.任何方法论都不会是跳过程，而是将大瀑布转换为小瀑布。

    9.并行和敏捷后势必影响到总体规划和系统思考，务必重视带来的需求不清和架构风险。

    网络图是进度中的一个重要工具，目的仍然是对发掘各活动任务的依赖关系并对活动 进行排序。在软件项目中为了加强迭代和并行，一个重点就是要将强制依赖转换为非强制依赖，要将对整个设计开发过程的依赖转换为对接口的依赖。因此这里也可 以看到架构设计和接口设计在整个软件开发中的重要作用，比如其他功能模块都要依赖系统管理和工作流相关功能，如果要等这些功能全部开发完成再进行后续开发 则其他资源等待时间太长，常用的处理方式就是架构只需要定出系统管理和工作流调用相关接口，后续开发工作全部可以提前介入和并行起来。多出的代价则是后续 需要有一个产品和功能模块的集成过程。

    10.通过架构和接口设计，将对整个功能模块的依赖转换为对接口的依赖。

    11.架构设计和产品集成是网络图中依赖关系需要分析的重要内容。其他活动依赖关系都是简单的基于小瀑布的线性依赖关系。

    12.迭代的思路仍然是架构为核心，架构接口定义不清不应该过早进入设计开发。

    对活动和任务工时的估算又是一个重点内容，估算跟任务粒度，复杂度，任务依赖，责任人技能，开发方法等多种因素相关。在没有多个版本的历史经验数据积累的情况下，很难真正实施参数估算或功能点估算方法，估算更多的是依赖于项目组成员 的经验。关键链法推荐两点估算法，将进度缓冲留到末尾，但仍然是基于估算工时是可以完成的，而不是倒推出的不可能任务。在进度压缩中我们可以多投入人力资 源，但有一个压缩的极限值，在这个临界点后投入再多的资源也无法再压缩。

    13.在没有太多历史数据积累情况下，最有效的估算就是依赖专家经验。

    14.根据关键链思路，不要在对单个任务的估算上预留太多的缓冲或余地。

    15.先确定活动或任务的责任人，再来估算工时以遍考虑个体生产率对工时的影响。