2 问题：作为传统的任务分配者所面对的项目管理

    传统软件生命周期开发方法论的产生是因为我们要控制不断增大的开发项目，以及对产生可靠的产品的工作量的评估和管理。这些方法论来源于建筑工程管理中的一些原则。结果，它们是强调可预言性的（在建一座桥时，工程设计师必须设计桥的每一个细节），并且是一个线性开发周期（即需求、分析、设计、开发）。根据这种可预言性，它们沿用了确定性的简化了的方法，这些方法依赖于任务分解，并且是基于稳定性的（即稳定的需求分析和稳定的设计）。作为项目控制的一个手段，这种刚性表现为顺从性。

    在过去，一些公司使用这些方法，并且现在也可能在使用。对于许多来说，这些方法论只是增加成本和复杂性，却给人们一种错误的安全感――管理就是通过详细的计划、度量和控制来做事。巨大的成本被过早的计划浪费了。我们认识到快速的迭代式开发和从用户那里得到不断的反馈是今天项目达到成功的前提。

    下面这个例子被公认为是原有方法论失败的代表案例：“伦敦救护系统”和“但佛航空行李系统”，巨大的成本超支和拖期。让我们来看一下Standish组织关于CHAOS的调查。在第一次调查中，成功项目18％，31％失败，53%挑战。在1998年的调查中有所提高，但也是26％成功，46%挑战，28％失败。研究还表明，在成功的这些项目中，它们的项目大小都控制在使用小团队就可以完成的级别上。这个结果很明显与敏捷方法论的原则一致。而且，我们还发现，很多已经确立的项目管理实践仍可应用于敏捷开发项目，只需要进行一些适应性改变并加强对其进行领导就可以达到。

    当管理者在使用传统方法论努力控制项目时，技术社区开始用敏捷方法来对付传统管理带来的挫败以及对他们的产品品质和士气所带来的影响。例如，那时的XP就几乎完全聚焦于开发过程。当技术社区支持这些实践时，却很少涉及敏捷开发项目的管理方面。这就暗示着：由于XP团队开发并管理他们自已的任务，对于项目经理的需求就很小。这并不奇怪，公司管理一直怀疑敏捷方法，不太接受它们。管理者希望着一种场景出现：满屋子的开发者做着他们各自的事情。。。。而“eXtreme”这个词并没有什么意义。

    抛开具体的方法论，传统的项目经理经常是作为制订并控制主要计划的人，这些计划详细地描述了任务、它们之间的依赖关系以及为完成最终产品而必须的资源。然后，项目经理监控任务的状态，对计划进行必要的调整。这种做法是建立在这样的假设基础上的，即组员是可以互换的个体，就象同一型号的螺丝。

    所以，对于熟悉传统方法论的经理，是很少有勇气在他们的项目中使用敏捷方法的。但这也不是必须的。事实上，敏捷方法的独立性使管理社区和技术社区在项目管理中趋于同一个焦点。

    3 答案：做为愿景领导者的项目经理

    最好的项目经理并不只是组织者（organizers）－他们使业务愿景、沟通能力、软管理技巧和技术头脑与他们的计划能力、协调能力和执行能力相结合。从根本上说，他们应该是领导者(leaders)。敏捷项目管理要求更高的领导技能。

    例如，XP团队在与客户的协作中，创建并监控他们自已的迭代计划。当XP团队工作时，对每一次迭代结果（等时长迭代）进行度量，并根据需要与用户一起调整计划。那么，如果项目不再需要一个详细的项目计划时，为什么还要项目经理呢？

    因为每个项目都需要一个领导者（leader）。敏捷方法把项目经理从工头的位置上解放出来，使项目经理可以专心作一个领导者（leader），把主要精力放在项目愿景上，激发团队勇气，促进团队协作，排除项目过程中的障碍，使项目开发过程顺利进行。项目经理不仅是项目运作的控制者，更应该成为适应性领导者――如果他放弃对旧风格的管理方式的依赖。

    敏捷开发项目的基本阶段与其它项目没有什么不同。项目经理还是必须定义和初始化项目，作项目计划，执行计划，监督并控制结果。但是完成这些步骤的方式却是不同的，需要项目经理去采用新的思考方式进行管理――思考CAS。