|
每位项目经理都可以成功地将敏捷融合到瀑布式环境中，这样可以提高项目的可预测性、提高成本效益，并促使项目最终获得成功。项目管理者联盟
曾经项目管理人员认为敏捷只是一种时尚。敏捷宣言发表10年来，这种方法已经渐趋成熟：它已经从边缘方法逐渐成为核心方法，并且从只应用于小型软件公司，发展到已应用于大多数的企业组织。敏捷不是银弹，它也需要适应复杂多变的企业环境。本文的目的正是要说明在企业环境里，项目经理怎样才能成功地在项目中应用敏捷。项目管理者联盟
我认为敏捷方法最好用于管理产品，不过用于管理项目也很有效。只是项目经理必须理解三条关键原则，那样才能充分发挥敏捷的力量，从而改善项目的交付成果。在本文中，我将讨论并破除关于人们通常认为“项目不是敏捷模式就是瀑布模式”的两个神话，再与大家回顾四种增量敏捷模型，并说明项目经理和其他特定的敏捷团队负责人如何使用这些模型。最后，我会推荐一个三层嵌套的“信封”模型，讲解在瀑布环境中，利用你对项目管理和产品管理的理解、结合你精心选取的管理方法，如何使用信封模型来管理敏捷项目。项目经理大可放心，在敏捷项目里他们的作用非常重要，不仅如此，对于大型项目的成功，他们也是必不可少的。PgMp.mypm.net
介绍项目管理者联盟
今年人们庆祝了敏捷宣言发布10周年。在这十年间，敏捷从项目管理界中的无名小卒发展成了主流的方法。2009年，在Version One的敏捷调查中，有84%(Version One，2009)的调查对象表示，他们在某种程度上使用了敏捷。2010年，这个数据跃至90%(Version One，2010)。然而，对许多企业高管、总监和经理来说，敏捷仍然让他们感到困惑、模糊并且不可信。项目管理者联盟
理解以下三条关键原则，每位项目经理就都可以在瀑布环境中成功地融合敏捷的价值准则和实践，从而提升项目的可预测性，促使项目最终获得成功：项目管理者联盟
敏捷不是用于PMI所指的那类项目的项目管理者联盟
敏捷中的计划工作，是一系列连续的步骤，没有明确的界限划分项目管理者联盟
混合使用敏捷方法和瀑布方法项目管理者联盟
在继续讲解前，我先介绍一下本文内容所基于的情境。我定义了两种企业类型：软件公司(独立软件供应商)和“其他公司”。由于敏捷方法能较容易地适用于“软件公司”，本文的重点放在如何在“其他公司”中使用敏捷方法。talent.mypm.net
软件公司的主要产品是软件，或者其产品的主要交付渠道是软件。按照这个定义，微软和Adobe公司是软件公司，亚马逊和易趣也是软件公司。我们之所以认为亚马逊和易趣是软件公司，是因为软件是他们交付产品或服务的主要渠道。与这种软件公司相对的是麦当劳和宜家。可以肯定，麦当劳和宜家也使用软件，但软件并不是它们的主要产品，也不是它们产品或服务的主要交付渠道。当然，它们确有自己的网站，但麦当劳并不通过互联网卖汉堡包。同样，虽然你可以通过网站订购宜家的产品，但是商店才是他们的主要售货渠道。转自项目管理者联盟
有一种处于灰色地带的第三类公司我也需要说明一下。这类公司在哪里都有一席之地。美国的银行和保险公司大都是此类灰色地带的公司。银行和保险公司既可以算是软件公司，也可以算是“其他公司”，这取决于他们的组织构成。如果企业按照产品或服务的业务线以水平形式构成，并且(或者)公司组织结构是由产品驱动的，软件是其产品或服务的主要交付渠道，那它就是软件公司。相反，如果组织结构基于工作职能划分，以垂直形式构成，例如分为市场营销、IT、和产品部门，那它就不是软件公司。这听起来很复杂，但在实践中，用这个定义，简单地确认公司中几个特定角色和他们的权力范围，就能较容易地判断出这家公司是不是软件公司。例如，如果公司有负责特定产品或服务的产品负责人，确认他的权力范围，看他能否为产品做所有的决策：市场营销决策、IT决策、网站用户体验决策等。如果产品负责人拥有对产品的所有控制权，并且能够做出从概念到客户的所有决策，那它就是软件公司，在这种企业环境中，推行敏捷方法会很容易。要不然，它就是非软件公司，想在这类非软件公司成功实施敏捷就需要做很多工作了。本文的重点就在于如何在这类“非软件公司”中实施敏捷。
敏捷不是用于PMI所指的那类项目的项目管理者联盟
根据美国项目管理协会(PMI)的定义：项目管理者联盟
项目是为了创造独特的产品、服务或成果所做的临时性工作。项目经理圈子
2001年2月在美国Snowbird Utah举行的软件开发者大会上，人们第一次提出“敏捷”一词。早期，敏捷只是指一些轻量级过程的集合，是针对那时更广泛使用的“重量级的”(笨重的)方法的回应(Hunt 2010)。与会者制定并发布了敏捷宣言(Beck et al.，2001)，这成为为敏捷运动开始的里程碑。参加这次会议的所有人都是软件开发人员。他们的关注点在于创建软件产品，而不是项目管理过程。通过我的个人访谈(van Bennekum，Hunt，Cunningham，Schwaber， & Cockburn, 2010，2011)，我发现他们关注的是：重量级的过程无法适应网络公司快速变化的特性，这种情况该如何应对。为软件公司做开发工作时，人们永远不会有软件即将开发完成的想法。软件项目经常会被改进、增强或以其他形式变更，而不像建筑项目或设计洗碗机这类项目。建筑物一旦建成，或者洗碗机一旦被设计出来并交付生产，项目工作就完成了。有可能你再去做内部改进(Interior Improvement，TT)项目或再设计新型的洗碗机，但是原来的项目仍然是完成了，要做的新工作是新的独立的项目。项目管理者联盟
这与现行的产品管理的本质形成了鲜明的对比：blog.mypm.net
产品管理是控制产品从概念到推向市场或向客户交付成果和服务的规程和业务流程，用以产生最大可能的商业价值。(Ebert，2009)club.mypm.net
产品管理关心的是产品的整个生命周期：从概念、发展，直到废弃。项目是关于创造事物的，当事物创造完成，项目也就结束了。项目不关心产品在整个产品生命周期的发展和改进。管理产品是敏捷能最有效地发挥作用的地方。花点儿时间思考一下敏捷的术语：产品负责人、产品需求列表、产品愿景、产品路线图，所有这些词语都关注于产品。敏捷实践能适用于需求变化的情况，也同样完全能够适用于产品管理。当你得知你将有第二个、第三个甚至第二十个发布时，它也只是简单地增加产品需求列表的范围，你知道，通过这样做，假以时日就能实现这些特性。而项目管理却不同，项目需要严密地管理范围、进度和预算，因为它们是结束项目的决定因素。项目管理论坛
使用敏捷管理项目training.mypm.net
人们无法普遍理解一些细微的区别。如果你理解了那些简单的区别，就可以成功地使用敏捷来管理项目。你需要做以下三件事情：项目管理者联盟
知道项目管理与产品管理的区别项目管理者联盟
规划好碰到项目/产品管理差异的临界点时应该做些什么项目管理者联盟
每一步都与管理层沟通PgMp.mypm.net
项目管理中需要管理三角约束：范围、进度、预算(有时人们把质量和/或资源也加到约束中)。产品管理也关注这些约束，只是对产品而言，它们是一些更加宽松的概念。项目管理者联盟
|
