一个成功的敏捷开发项目有可能将瀑布式开发组织由缓慢的、庞大的发布转变为快速的迭代式循环发布。一旦组织已经牢牢掌握敏捷基础知识，那么该组织就可以从原来的年发布周期改为周发布周期，这种转变非比寻常。

以50个快速发布取代一个大型发布有几个优点。通过早期发布获得重要的数据特性，开发团队能够更交付价值数据。当判断出需求是错误或者误解时，他们也能够迅速改变方向，而不是沿着错误的方向继续工作。这些优点是很重要的，要实现这些功能并不容易。

当他们离开一个既定的开发项目，如由瀑布式方法转向更多的使用敏捷方法时，许多项目经理被敏捷方法的基础知识所困惑。并不是你自己有这样的困惑。这里我们已经整理出来一些敏捷开发基础阶段会出现的常见问题。

谁促进敏捷计划、设计及需求收集？

根据行业分析师兼顾问Mary Gorman所说，涉及引领敏捷组织的人可以是任何一个人。如果组织处在一个Scrum环境中，那么这个领导者可以是敏捷教练。也可以是产品冠军，他来自业务部门并且运用娴熟的业务知识将不同团队和不同微焦点聚集在一起，一同为综合业务、顾客及技术需求服务。

三个实例中没有一个对于领导角色的选择是显而易见的。Gorman说，为了一个特定的产品而开发新平台，可能不仅需要技术上的引领，而且也需要推出一款新产品或者添加一种可以连接到业务领域产品冠军的新性能。尽管如此，这个领导者可能是声称没有足够信息的QA人员，而测试人员却需要获得更多细节。

敏捷管理方面的努力需要团队整体的付出，可能不需要任何一个领导者。Gorman说：“我们需要一个框架，团队中的每个人能够都能很好的参与其中、引导成员进行对话、提出更有针对性的问题或提供独特的见解。”

引入敏捷管理意味着要扔掉以前的文档吗？

敏捷宣言的四大原则之一是要评估全面文档层面的工作软件。然而，记住如下四条原则相当重要。“这就是，如果项目的价值在右边，那么我们评估项目左边的价值更多一些。”许多刚接触敏捷管理的人（可能是有丰富经验的专业人士）误认为敏捷方法中要避免使用全面的文档。根据EBG咨询公司的创始人兼原理分析师Ellen Gottesdiener所说，这根本不是事实。

Gottesdiener认为，不要询问敏捷团队是否应该生产软件文档（因为答案是肯定的），相反，项目经理要询问的是“对于项目的运行哪类文档是最有价值的，及什么时候生产是最恰当的。”团队应该区分产品文档——“对于销售、维修和使用产品有很高价值的文档；与流程文档——“探索和交付期间所使用的进度或者交易信息”。

如何控制敏捷项目中的描述点？

故事点（story point）的使用是衡量长期、可能会出现很多变化的敏捷项目长度的最基础方法。当开发人员进入一个新项目——尤其是如果他们之前从未接触过这个项目——对于团队来说，估计项目每个阶段多久能完成是非常困难的事。另一方面，相对于其他要求来说，衡量满足一个需求有多复杂就很容易了。一般而言，一旦团队在新项目中具备了一些经验，那么其复杂性就会很好的反映出实际交付时间。项目初期，故事点方法可以使那些不确定的问题固化并可测量，因此，未来不确定的问题可以更精确，也可以衡量团队的进程。

尽管他们也使用过其他敏捷方法，但是，描述点方法对于Scrum过程特别有用。敏捷及敏捷教练认证专家Yvette Francino解释说，规划项目时使用故事点方法是复杂的，因此也很难估计。每次迭代的尾声，团队都将会完成一定数量的故事点。这个数量就是团队的速度，因为这可以衡量团队运行速度如何。

起初，这个速度可能会有点波动，但是，当团队成员及项目经理更加理解故事点对于特定项目的意义时，这个速度就会达到平衡，并且变得更加稳定。Francino说，故事点系统最初可能要做一次WAG评估，但是当需求细节发生变化，从一种迭代状态转向另一种迭代状态时，那样做总比陷入决定具体时间表的困境要好得多。

当敏捷项目遇到瓶颈时，项目经理应该做些什么？

尽管我们付出了最大的努力，但是即使是敏捷项目的专业人士，在项目的运行中也会遇到瓶颈。不知怎么的项目就会被负面因素所影响。但是，不必担心。不会出现一直占用工时或者延缓开发周期的现象。如果项目经理能以敏锐的目光及清晰的思路去发现项目所存在的问题，那么解决项目问题，并使项目继续运行就不会那么困难。

产品管理咨询专家Scott Sehlhorst解释了根源分析如何帮助延迟的敏捷项目解除停滞现象。他解释说，如果项目停滞，就意味着项目团队不生产任何东西或者生产出来的产品也是错误的。如果团队能够稳定的生产产品，但是却没有什么进步，Sehlhorst说是时候检查一下关键性指标了(KPI)。如果团队朝着错误的目标发展，那么他们最终没法生产出正确的产品。Sehlhorst告诉我们“许多团队都在衡量什么指标容易估量，而不是那些重要的指标要估量” ，这是一个常见的缺陷。

一个人如何成功地管理多个敏捷项目团队？

当项目经理带领敏捷试点团队成功地加入项目组织时，他们经常带领多个团队，因此组织可以看到更多成功的敏捷。但是带领敏捷团队是非常费时的工作，横向扩展多个团队可能非常困难。不过,这可以做到。经验丰富的测试人员及团队领导者Amy Reichert解释说，当在多个团队之间进行细分时，成功管理时间的秘诀就是消除一切外界干扰。

如果一个敏捷教练要同时带领两个或者两个以上的团队，Reichert建议，她必须集中精力关注来自敏捷团内部的需求。另外，即使是能改善敏捷教练小组的项目，也需要对她领导的团队投入时间和注意力。也许有人会说，分些精力干其他的事情应该是可以的，但是Reichert说任何分心都会造成更多的干扰。自身的每一个干扰并不会影响敏捷教练的能力，但是像这样的20个干扰堆积起来就会破坏其有效地支持多个团队的能力。