项目时间表的演变

如果你这周刚好在奥兰多，并且打算来听我关于敏捷PMP的演讲，请先不要阅读这篇文章。根据我上周在温哥华收到的一些反馈，我正在修改我的演讲。我可能会用这篇文章中包含的一些图片和解释来帮助解释敏捷项目计划及其不同之处。我想把这些写出来，以澄清我的一些想法，并感受一下这种推理方式是否可行。

你正受益于我试图发展一个想法;-)没有什么比向几百人大声思考更好的了。谈话结束后我会告诉你进展的。如果你在明天之前有任何建议，我可能会把它们放到谈话中。如果你有评论，现在是时候发表了。

在我开始之前，我想解释一些事情并给予一些免责声明。我使用MS项目创建一系列插图，描述了传统的项目时间表如何发展成为敏捷项目计划。让我们清楚，我不推荐你使用MS项目来管理敏捷项目。我不需要任何人吓坏的是，一些敏捷的家伙正在推荐敏捷项目的MS项目。事实并非如此。

我选择从MS Project开始的原因是，甘特图是许多项目经理理解的语言。当敏捷社区与传统项目经理讨论敏捷时，我们需要从人们使用他们目前理解的工具的地方开始。用MS project管理敏捷项目并不是不可能的，只是甘特图的基本范式并不能真正工作。该工具本身并不是为协作而设计的

传统瀑布式项目计划

许多项目经理从这种对软件开发项目计划的理解级别开始。它良好的感觉......你明白你要建造的东西......你决定如何建造它......你建立它......你测试它......你看看客户是否喜欢它......如果他们这样做，你会部署它。简单，呵呵？

我用这种方式管理项目，并取得了一些成功。要使这类项目成功，您需要对将要构建的内容有很大的确定性。改变并不是瀑布式项目的朋友。您的项目团队还需要大量的稳定性。你不能让人们在你的项目上进进出出，然后被拖到其他工作中去。

这通常意味着您的项目最好在组织优先级队列中处于较高的位置。

通常情况下，我们的实际情况是需求确实发生了变化，并且人们正在从事其他项目。这使得我们的项目延迟和不可预测。更麻烦的是，我们经常发现他们已经晚了，超出了预算，直到为时已晚。我们需要提高可预测性，缩短交付周期，更快地将产品推向市场。我们需要改变我们对交付的想法，并改变我们的项目管理方法。

瀑布式项目计划的第一个演进是将项目分成更小的阶段。

分阶段交付

这种方法仅仅设计为使我们的项目更小并使产品更快地推出。较小几乎总是更好，但相控计划遭受了许多与瀑布计划相同的问题。为了使这种方法工作，您仍然需要非常稳定的要求和一个非常可预测的项目团队。这种方法并没有从根本上解释解决问题，但它确实可以帮助您更快地实现它。

分阶段方法的核心问题之一，就像完全成熟的瀑布方法一样，是人员是专门化的，他们的专门化在项目的生命周期中不是100%需要的。这导致了矩阵项目团队和矩阵管理。当人们开始从事其他项目时，而这些项目运行较晚，这将影响您在需要时让人们回来的能力。

为了解决相控方法的问题，我们不仅需要在更短的周期中提供，我们需要让人们致力于我们的项目。

重叠的项目阶段

这就是重叠阶段方法的用途。一个聪明的项目经理会尝试从项目中抽出一些等待时间，并重复许多活动。这是一个很好的举措，它让人们专注于我们的项目，他们更频繁地保持忙碌，而不太可能被其他计划所吸引。

您还可以从图中看到，这种重叠可以对您的时间轴产生重大影响。你通常可以早点把工作做完。这种方法是朝着正确的方向迈出的一步(从使用的角度来看)，但是并不能解决我们的问题，因为我们的项目计划很脆弱，无法抵抗变更。

将阶段缩短为迭代

下一步是我们项目规划模型的演变，但不再解决了我们的任何基本调度问题。它确实允许我们更注重交付并从提供工作软件的过程中学习。思考是，如果较短的阶段更好，并且重叠阶段使工作更快，请让我们在类固醇上施加这种方法。

这种方法是我开始了解迭代和增量开发的地方。在我担任软件项目经理的早期，我将迭代和增量交付理解为一系列较短的、重叠的瀑布式项目。作为这些项目的项目经理，我的主要工作之一就是管理重叠部分，确保人们了解我们在做什么，什么时候需要他们。

即使在我们的项目计划中有了这种复杂程度，即使有了我们已经实现的资源利用率和时间轴收益，当需求变化和时间表不能按照计划进行时，我们的项目仍然会受到影响。我们已经解决了一些资源和优先级问题，但在这个过程中，我们创建了一个相互依赖的网络，这只会降低我们有效应对变化的能力。在某些方面，我们的项目时间表变得比以前更加脆弱。

使迭代跨功能

迭代和增量发展不应该是一系列重叠的瀑布。迭代的目的是让所有技能集在甲板上致力于共同的迭代目标。每次迭代都有一个目标和一组功能，即它应该提供交付。通过让每个人都集中在同一组可交付成果上，我们能够处理迭代本身的变化......没有人搬到其他工作......没有人必须回溯。

包含了依赖关系，级联影响可以保持到最小。

迭代时间盒是固定的，不重叠。团队为该迭代开发一组计划的功能，并作为团队审查迭代的结果。有机会从我们的进展中学习，并在下一次迭代开始之前采取任何纠正措施。如果将更改引入到项目中，它将在下一次迭代中被计划，并且该更改的影响将级联到项目中。

大多数采用敏捷的团队发现自己处于项目成熟度的这个级别。他们已经引入了迭代和增量开发，但是没有采用其他一些使其工作所必需的组织变更。在这一点上，我们仍然没有解决人们被从我们的项目中拉出来的问题。我们面临着受到竞争优先事项影响的风险……我们无法作为一个有凝聚力的团队发挥作用。

另外......没有什么特别敏捷的这种方法。我们仍然可以进行大量前置设计，传统的变革管理和预测项目控制。我们可以承认它是一个正确的方向的一步，但它不是敏捷。

进一步缩短迭代并关注价值

从迭代和增量，到开始看起来敏捷的东西，您需要进一步缩短您的交付周期，并创建分配给您的项目100%的跨职能团队。

通过缩短交付周期，项目经理可以更少地关注产品如何交付，并且更快地送达，并且有多快。该团队对举行的送货目标负责，并更有能力决定完成的内容。该团队可以决定如何最好地使用他们的时间来满足迭代的目标。项目经理获取有关项目如何以工作软件的形式进行的真实经验数据。

通过将人员100%分配到我们的项目中，项目经理需要较少地关注活动排序，这可以委托给团队。把这个责任交给团队可以让他们更有创造性地解决问题。他们不再负责完成任务，而是负责交付价值和实现目标。项目经理更加关注于跟踪价值流，消除可能出现的障碍，以及与组织的其他部分进行沟通和协作。

在这个成熟程度上，项目经理通常仍然认为预测性心态。他们仍在尝试预测价值的流程，并提前安排所有迭代，但已移动到价值聚焦规划模型，而不是基于活动的计划模型。

敏捷项目计划

敏捷项目计划实际上只是项目发布和迭代的序列。它是送货的基本节奏，该团队决定组织各地提供产品。特征在排序的积压中保存并根据我们对不断发展的产品学到的内容进行迭代调度迭代。项目经理衡量功能传递，迭代迭代的流量，以与组织进行通信团队如何取得进展。

如果需要向项目中引入变更，可以像添加其他特性一样将其添加到backlog中。团队与业务部门协作，频繁地重新确定优先级。亚博vip9通道因为我们专注于在极短的周期内交付可工作的软件，所以业务部门需要决定什么时候将产品推向市场。亚博vip9通道

无耻地宣传VersionOne……

从纯结构的角度来看，像MS Project这样的工具可以用来管理敏捷项目。当团队尝试这样做时，他们通常处于完全采用敏捷之前的一个阶段。他们仍然在试图预测功能的构建顺序，而不是管理与业务协作的价值流。亚博vip9通道

敏捷项目管理工具喜欢VersionOne企业更多地专注于为团队创造合作，计划短期，衡量和评估其进度的空间。敏捷的工具集中在预测项目规划中的重点少，更多就在团队与团队与企业之间进行了沟通。亚博vip9通道

综上所述

向传统的项目经理解释敏捷通常是相当具有挑战性的。你也许能把核心思想讲清楚，但你可能会得到一些茫然的目光和呆滞的眼神。这些都是聪明人，不是他们听不懂你的话，而是他们在努力寻找如何从这里到那里。他们不完全明白为什么他们一直从事的活动并不总是适用。

我希望这能帮助您理解快速变化的项目与传统项目的不同之处，以及它们不能使用传统方法进行管理的原因。同样，不要把敏捷看作是替换你所知道的东西，而是向它添加，向你的工具包中添加额外的工具，以帮助你在面对不确定性时可靠地交付。

写完这些后，我真的在重新考虑明天是否要使用它。鉴于我还需要说些什么，我不确定我能说出这么多话。就像他们说的，这很长因为我没有时间把它变短。一如既往地感谢你的阅读!