使用AgileCC关键链进度管理软件前我带着最关心的两个问题，第一个就是对资源约束下进度计划编制的支持程度，第二个问题对接驳缓冲和项目缓冲的计算和分析。
首先假设了一个简单的软件开发项目计划，该项目除项目经理外只有1个需求人员，1个设计人员和2个开发人员。需求只能承担需求开发任务，设计只能做设计，编码只能完成编码任务，相互之间不能串角色。
整个任务分三个迭代周期，具体哪个先开始没有明确的要求，每个迭代周期中的需求，设计和编码任务存在强制依赖关系。所有编码都完成后才可以进行系统测试。在创建完任务后，设置了任务的最可能工期和悲观工期，以方便进行缓冲区大小计算。工期设置后对每个任务进行了资源分配，资源分配完成后通过自动化资源平衡进行了试验。自动资源平衡后的结果很另人满意，整个进度计划根据资源约束进行了重新计算和排序，需求和设计由于都受到一个资源的约束，系统都根据资源约束将原来并行任务进行了串行，并自动计算了三个迭代周期哪个先开始，以获取最短的项目工期。
对于接驳缓冲和项目缓冲长度，AgileCC支持两种常用计算方法。一种是“SRSS”，使用这种方法，必须输入任务的平均工期和最坏情况工期，AgileCC用任务链上每个任务的两个工期差的平方和再开平方，作为任务链后缓冲的长度。这种计算方法假设各个任务工期变化互相独立，有时候误差比较大，而且得到的缓冲长度偏短。一般情况不推荐使用这种方法。另一种方法是固定比例，这是一种很简单的计算方法，用任务链的长度乘以一个比例系数，得到的结果直接作为缓冲长度，比例系数通常是50%，也可根据项目工期的不确定性大小调整比例系数。
在自动计算完成后，我们对关键链进行重新分析，然后增加了项目缓冲，高亮了关键链后可以得到如下图表。
从图中可以看到根据可能时间和悲观时间，项目自动计算出需要增加5天的项目缓冲。当项目网络图中的处于关键链中的任何任务出现延迟的时候，都会消耗掉项目缓冲。红色标记为关键链上的任务，对于橙色，黄色和绿色标记为：
被标为橙色的任务，如果ID为8和9的任务，虽然不是关键任务，但这些任务和关键任务之间没有足够长的间隙（接驳缓冲区），在最坏的情况下，这些任务会延期并碰上关键链，导致项目缓冲被侵蚀。而且标为橙色的任务即时提前到最早可以开始的时间，也无法留出足够长的间隙保护关键链。这些任务在项目执行过程中也应该密切关注，在编制计划的时候最好安排这些任务尽可能早的开始。
被标为黄色的任务，如ID为15的任务，虽然不是关键任务，但这些任务和关键任务之间没有足够长的间隙（接驳缓冲区），在最坏的情况下，这些任务会延期并碰上关键链，导致项目缓冲被侵蚀。和标为橙色的任务不同的是，如果将这些黄色的任务提前一段时间，或者插入接驳缓冲任务，将会有足够的间隙保护关键链。在编制计划的时候，可以考虑提前这些任务，或者加入接驳缓冲，以充分保护关键链。
被标为绿色的任务在最坏的情况下也不会碰上关键链。
而这些标记的计算正是通过缓冲实际大小与任务的悲观时间比较得出来的，有很强的指导意义。对于接驳缓冲暂时还没有试验，对于任务实际执行过程中对缓冲消耗的跟踪也还没有试验。该软件提高了时间缓冲，资源缓冲，能力约束缓冲，同时还支持多项目间关键链进度管理，这些都还需要再进一步研究和使用。
您的位置：
