瀑布流、 Scrum&企业项目管理、敏捷原则

 

敏捷运动创造了项目完工的速度，但我们需要花点时间来澄清相关的概念和理解。首先，敏捷不是一种方法论。敏捷是一个由包含了73个词的运动宣言和12条原则组成的运动。该宣言及其包含的12条原则，旨在优化软件开发项目。换句话说，敏捷宣言和原则的精神，实际上可以更广泛地应用于其他领域，并且在120VC项目管理标准中得到了认可。

 

瀑布流和关键路径方法

瀑布流的概念是由一位名叫温斯顿·罗伊斯（Winston Royce）的计算机科学家在20世纪70年代提出的。当时他写了一篇名为《管理大型软件系统的开发》的论文。该方法旨在利用当时可用的技术，来优化软件系统的开发。简言之，这篇文章概述了应该如何分阶段地完成软件开发工作。并且，在当前阶段的工作完成之前，不应开始后续阶段的开发工作。本质上，这个概念要求将软件开发项目的工作组织成一个单一的线性工作流。

企业项目管理绝不会采用瀑布流的方法，因为企业项目通常涉及多任务、单一管理团队以及外部供应商。而瀑布流是完成此类大型项目的效率最低的方法。

关键路径方法是杜邦公司的摩根·R. 沃克（Morgan R. Walker）和兰德公司的小詹姆斯·凯利（James Kelley Jr.）在20世纪50年代后期提出的。一般来说，关键路径方法用于企业项目管理。关键路径的概念假定每个企业项目需同时执行多个工作流。并且考虑到大多数企业的成本和进度约束，这些工作流中的每个进度都被压缩或“破坏”，以确保整体的成本和进度得以优化。

人们谈论敏捷或瀑布流开发流程时，他们是在谈论软件开发的框架，而不是按步骤操作的方法论。

 

Scrum和企业项目管理

Scrum1是一种软件开发方法，具有许多有据可查的最佳实践步骤，可以真正优化企业频繁交付可用软件的能力。

通过要求一支专门的跨职能团队，定义任务的期限不超过一天，并且每天开会来评估项目进度， Scrum最佳实践能够提高工作效率并创造速度。拥有一支专门的团队，并将工作分解为几个小时或一天的增量，管理者很容易可以看出哪里需要改进以提高团队的生产力。

企业项目管理与多个多元化或“专用”团队合作，将任务分解为最多十二小时的增量，并使用关键路径来预测进度、进度滞后和障碍的影响。这种针对企业项目的方法，使项目团队可以做出日常决策，确保项目目的和目标的实现，并确保在既定的最终日期和成本下尽可能地交付。

我认为， Scrum是开发工作软件的最有效方法。通过Scrum最佳实践进行优化的开发企业，不会浪费时间或金钱。 Scrum唯一的缺点是，它无法满足公司将计划或投资组合中的资金和团队成员从有盈余项目分配到需要的项目的需求。而且，它不支持企业项目中多元化团队成员对跨组织协作的依赖性。

备注

这不是对Scrum的批评。 Scrum联盟也承认，要支持Scrum之外的项目可能需要一些特定的活动。

 

话虽如此，我们仍然认为Scrum是进行软件开发的最佳方法，并且敏捷原则是任何项目管理标准的理想选择。因此，我们的项目管理标准在企业项目管理中结合了敏捷原则。通过将传统的企业项目管理技术与敏捷原则和Scrum最佳实践结合，能够为大规模的敏捷框架开发提供第一个操作方法标准。

我们的大规模敏捷框架，使我们的团队成员和我们的客户能够：

1. 充分利用Scrum最佳实践带来的变更效率和速度。

2. 克服Scrum设计中缺乏对项目和项目组合需求支持的缺陷。

3. 允许Scrum的交付成功可用于有效地管理跨组织的协作依赖关系。

4. 允许将富余项目中的资金和团队成员分配给需要的项目。

 

实践出真知……

敏捷，更确切地说， Scrum创造了迅速适应市场需求的优势，但这种优势是有代价的。 Scrum的确可以优化团队成员对时间和费用的利用，从而快速创造有价值的成果，这是不可否认的事实。但是，拥有更多的成果、产品和工作软件，意味着需要花费更多的金钱和时间，就这么简单！因此，在决定采用敏捷或Scrum文化之前，请问问团队成员：“我们每年真正需要引进的改变是多少？”

 

更多的变化意味着更高的成本。如果你的企业需要跟上谷歌或亚马逊的改变步伐才能获得竞争优势，那么Scrum就是最佳的选择。但如果你决定使用Scrum的理由是你的团队今天所做的改变太慢，或改变的量没有达到预期，那么你所寻求的改进实际上应该是优化当前的工作文化。

因为团队未能按照预期的效率处理当前的项目而做出引进敏捷（高频率改变）的文化，就像是要求幼儿园的学生先学会驾驶大型喷气式飞机才能升入一年级。

也就是说，在这么多非常有价值的Scrum最佳实践中，只有两种不符合企业项目管理的规定。第一种是要求拥有专门的团队；第二种是“即时”计划的做法。企业项目之所以使用多元化的团队成员，或拥有“非专用”的团队成员，是因为企业项目本质上是独特的，通常不会年复一年地重复出现，且每个项目都需要不同领域的专家。

这些领域专家来自公司现有的人才库，因为他们对公司的产品、流程和文化（领域知识）有所了解，或在专家不需要具备领域知识（企业文化）的情况下，由供应商提供。而且大多数企业项目并不需要全职的领域专家。专用的团队将会导致大多数团队成员无聊地坐在一旁，等待其他人完成工作之后才能开始自己的工作任务，这肯定不是利用时间和金钱的最有效方式。

与Scrum项目一样，企业项目也会采用“即时”计划。区别在于，在不存在跨组织协调依赖性的开发项目和专门团队以及企业项目中，“即时”有着不同的含义。

Scrum项目在每个项目开始时就确定了需求，但会等到每个冲刺开始时才会计划与用户场景相关的任务计划。 Scrum之所以能够做到这一点，是因为团队成员都是专用的，可以随时待命去处理冲刺计划会议中分配的任何内容，并且团队成员必须始终具备相关技能，才能够完成与用户场景相关的任务计划。

企业项目之间会抢夺多元化或非专用的团队成员。如果你未能根据任务的先后顺序安排提前预定这些团队成员的档期，那么在你需要他们进行工作的时候，他们可能无法提供服务。因此，企业项目的“即时”计划，在项目伊始就应该完成了。

最后要注意的是，敏捷的另一个原则是优先响应计划的变更。这就意味着即使你在项目开始时就创建了整个计划，在变更出现时，也应该先遵循这个原则。在企业项目上，驱动变更需求的有两个原因：障碍和需求。

当只能通过更改范围才能克服的障碍出现时，我们将更改范围！当团队被要求更改范围时，我们将更改范围！

Scrum和企业项目都能够控制范围的更改，这可能与常规认知不同！在敏捷中，范围更改决定由产品所有者做出，然后才能对产品待办事项列表进行任何更改。在企业项目上，范围更改由项目负责人决定，然后再添加到工作计划中。这有什么不同？没有任何不同！

企业项目对更改的响应，是敏捷的“检查和适应”这一最佳实践可以发挥作用的地方。如果只有通过更改范围才能克服完成项目的障碍，那么常识和敏捷原则就决定我们必须这样做。如果企业项目的项目负责人或敏捷项目的产品所有者想要更改范围，则他们之所以做出此决定，肯定是因为他们认为这将为其客户或项目受益者带来好处或创造竞争优势。

 

敏捷原则和120VC标准

如前所述， 120VC全盘认可了所有的敏捷原则。下面我们将逐条介绍敏捷的各项原则，并解释这些原则如何与我们的企业项目管理方法整合使用。需要注意的是，因为敏捷原则是专门为软件开发编写的，因此当你在阅读各条原则时，如果看到“软件”一词，请将其替换为项目管理常用的“产品”或“价值”。

例如，敏捷的第一个原则是“我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意”。将这个原则应用到与软件开发无关的企业项目中时，我们将其解释为“我们最重要的目标，是通过持续不断地及早交付价值使客户满意”。

在一个敏捷项目中，团队由产品负责人、 Scrum主管和开发人员组成；敏捷项目也有外部利益相关者，例如商人。在企业项目中，团队由项目负责人、项目经理、职能管理者和领域专家组成，我们也有外部利益相关者。

120VC认为项目团队和外部利益相关者都是“项目利益相关者”。我们遵循以下敏捷原则：

1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。

与大多数企业项目标准一样，我们从计划项目开始。为了遵循此原则，我们鼓励项目团队在计划工作的同时开始工作。毕竟，开始得越早，就能够越早完成！

在计划期间，我们要求将任务分解为不超过12小时的增量。将任务分解为12个小时的增量可以实现更精准的估计，确保进度的透明性，并能在很短的时间内迅速发现障碍。尽早发现障碍，意味着可以尽早解决障碍，这可以确保项目尽可能快速地完成。这也意味着项目团队每天都会交付有价值的东西。

2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。

我们认识到，无论项目的规划做得多么周全，都无法确保万无一失。因为我们不可能在项目计划中预判需求或经济的变化。在撰写本书时，美国电话电报公司（AT＆T）宣布了收购时代华纳的意图。这立即给他们的项目组合带来了巨大的变化，这些变化是项目团队在规划项目时无法预测的。

我们的项目管理标准欢迎变革，并专门为此创造了一个新概念——计划外的工作。计划外的工作是指未包含在项目的工作方案中，但对于实现项目目标却是必需的工作。

如果这些计划外的工作不影响项目进度或成本，则由团队自行决定是否完成，而无需更改流程。

显然超出团队工作范围或影响项目成本和进度的变更，将通过Scrum规定的相同检查过程进行处理。即项目负责人对其进行评估，以确定其业务影响以及对成本/进度的影响。如果项目负责人在检查后决定进行更改，则将其添加到工作计划中。工作计划就等于软件开发项目的产品待办事项列表。

3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

120VC项目管理标准要求任务分解不超过12小时的增量。将任务按时间拆分为以12小时为单位的增量时，就能够确保任务每天都会开始和结束。同样， 12小时增量的工作形式，将迫使团队成员专注于单个任务直到完成，而不是一次执行多个任务，并导致所有任务的完成时间都被延长。

与软件项目不同，企业项目很难每天交付具体的功能，但是可以每天为利益相关者交付价值。

例如，有一个IT项目计划以不超过12小时的增量的形式，来完成构建数据中心这一任务。那么团队每12小时就需要交付一些东西，无论是安装服务器还是机架布线。如果该项目被取消，则这些资产将保持原状并作为下一个项目的前期准备。

如果有一个建筑项目要建造一个12层的建筑，没人会完成一层公寓的建造并开始让人搬进来之后，再开始第2层公寓的建设。但是，如果一个建筑项目以12小时为增量计划其任务，则每12小时就会完成一些特定的工作，例如一间公寓的管道铺设或电气设备的安装。无论先完成什么具体的任务，如果该项目被取消，则已经完工的资产将一直存在，并随时可以让下一个投资者在上一个投资者未完成的地方开始。

最后，企业项目的客户希望有自己的项目，能够以最小的成本在最短的时间内完成。我们开发的120VC工作计划的规则，确保每一个工作计划都能够积极迅速地推动项目的完成，并且不浪费任何时间或金钱。这也是领先全球的项目管理技术，学到就能从中获取巨大利益。

4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。

Scrum建议专门的开发团队包括7到9个业务团队成员。当我们说这不是完成大量工作的最有效方法时，每个人都会认同！

企业项目需要来自许多不同职能部门（建筑、信息技术、市场营销、销售、战略与计划、法律、人力资源等）的团队成员，并且还需要兼职的领域专家提供服务。我们不可能把领域专家指定给不需要他们全职工作的项目。

然后就是“一个人到底可以有效地吸收多少变更？”这个问题。想要了解成年人的学习能力和企业吸收变化的能力，了解科尔布（Kolb）体验式学习模型是关键。

科尔布描述的体验式学习包含了四个步骤，分别是：具体经验、反思性观察、抽象概念化和主动实验。学习者需要重复此循环，直到掌握新概念为止。

科尔布的体验式学习模型能够解释，为什么无论企业有多么希望迅速实现改变，变更实现的速度都需要取决于团队成员掌握变化的能力。

因此，我们对原则4的看法是，必要的业务人员必须与必要的团队合作。并仅在必要时合作，而非“即时”合作，以确保尽可能积极地推进项目。

120VC项目管理标准采用了多种技术来实现这一目标。通过制定工作计划，我们能够知道未来何时会需要业务人员和项目人员的互动，并提前做好安排。而在规划会议的安排时，我们遵循的原则是“宁早勿迟”。

就像Scrum项目一样，我们也具备了识别障碍的一套非常成熟的方法。每当团队成员遇到障碍时，他们都会将其上报给项目经理，并通过协作找到解决方案。项目经理使用关键路径对障碍进行优先级排序，并与领域专家一起确定合适的解决方案。

如果障碍在短期内影响了项目的结束日期、成本或范围，我们会想办法立即要求项目负责人参与问题的解决。

本质上，我们的每一项管理方法，都是通过确保合适的项目团队成员，在适当的时间与适当的业务人员合作，来“最大化完成工作量”。

备注

上面提到的职能团队全部配备专门的团队成员。 Scrum不仅是开发团队的最佳方法，而且是任何专门职能团队都可以运用的优化需求管理的方法。

 

5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

这是我个人最喜欢的一个项目管理原则！在120VC，我们发自内心地相信，在进行项目管理时，我们真正做的，是领导人员，而非管理项目。我们彼此之间建立深厚的人际关系，而不仅仅是业务联系。我们认为项目各个层级的人员都能够获得成功。作为项目经理，我们的职责是竭尽所能地确保项目团队获得成功。只有这样，我们才能实现个人的成功。

此外，项目管理的方法，实现项目目标和目的所需的每项任务，以及每种障碍的解决方案，都应由领域专家来提供。与在Scrum中一样，我们认为领域专家是专门人才。而项目经理的工作，是收集信息，确保团队成员明确优先事项；制定决策和消除障碍等。所有这些任务，的确要求我们成为强大的领导者。

但请记住，领导者并不总是决策者！

6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

首先，在120VC，我们相信可以通过沟通更好地领导团队。进行交流的唯一目的，是尽可能积极地推动项目的完成。因此，本书中提供的每个方法，都是为了实现最好的面对面沟通效果。我们将沟通拼写为l-e-a-d （管理），而将对话拼写为m-e-e-t-i-n-g （会议）。稍后在下文中再详细介绍这两个概念。

为了强调这一原则的重要性，我们需要先解释两个重要的事实。在概述这两个重要的事实之后，我再解释如何利用它们进行协同工作。

第一个事实，项目经理将大部分时间用于帮助团队成员克服障碍。人类天性不服输，所以我们通常领导着一群不喜欢失败的人。因此，无论何时遇到障碍，我们所领导的团队成员（包括上级、下级、同级的同事），要么敢于挑战，要么准备逃跑（人在面临危机时的两种本能反应）。当团队成员处于这种应激状态，或压力很大时，他们可能会带着个人情绪参与或开展工作，这将导致产生误解和摩擦的概率增加，并限制了项目经理的领导能力。

第二个事实，有效的团队领导，要求项目经理能够建立融洽的团队关系，因为人们通常选择听从他们愿意跟随的人。尤其是团队成员还可以将自己项目失败的原因归咎于优先考虑了你的项目需求！请记住，员工可以像选择航班那样，选择自己的雇主。当团队成员自己的项目和团队项目之间存在需求冲突时，你将不可避免地迫使团队成员做出孤注一掷的选择！但他们不会为独裁统治者或任务分配者做出这样的牺牲，他们只会为自己愿意跟随的领导者这么做！

“领导者要知道他们没有控制权——他们只对自己管理的人负有责任！”

——西蒙·西内克

 

那么，为什么面对面的沟通是传达信息的最有效办法？对此已经存在许多研究，所有的研究都得出同一个结论：想要传递的信息中，只有7%可以通过词汇传递；38%通过声音要素（例如语调和语音变化）；而55%的信息是通过非语言要素（例如面部表情、手势、姿势等）传达的。这意味着要成为最有效的领导者，并避免可能的理解错误，你需要与成员进行面对面交流！你需要让团队成员看到那55%的信息，而你也需要看到他们那55%的信息。

要点精炼

我们进行沟通的唯一目的，是带领我们的项目团队，尽可能积极迅速地推进项目，尽可能高效、迅速地完成任务，并尽量在第一天就能够实现100%的通过率。

 

7. 可工作的软件是进度的首要度量标准，敏捷过程倡导可持续开发。

我们认为项目管理需要提前规划，并且认为归档很重要。但我们不认为文档归类是能够推进项目的操作。我们认为，这个操作能够确保我们掌握必要的信息，做出积极迅速地推进项目的必要决策。当涉及文档归类时，我们严格坚持文档够用即可这一原则。而当利益相关者坚持认为文档应包含市场虚假信息或以后会更改的任何内容时，我们会坚定拒绝。

我们认为，信息收集的过程能够产生更大的价值。例如，定义项目的章程应包含项目的内容、原因和方式。章程的信息收集工作，应被用来促进利益相关者对项目的支持。该文件本身，只需要包含与项目利益相关者共同制定项目相关内容时所达成的协议即可。而最终保留的文件，仅需包含足够的信息以确保相关利益者对协议负责即可。

鉴于人们需要完成规定的所有工作，因此任何项目规划的方法都必须尊重人们的工作方式。这一点至关重要。因为研究表明，如果人们的工作量太少，他们会丧失工作的动力，导致表现不佳。但如果工作量过多，他们会因为长期处于强压的应激状态，而出现“收益递减”效应。研究已经表明，每周工作40小时，将确保人们能够以最佳状态和效率工作。

考虑到这一点，我们在规划项目时采用了半场工作制。半场工作制要求管理者在安排任务和分解工作时，所安排的工作任务永远不得占用成员每天可用时间的50%以上。如果一项任务需要一个人花4个小时才能完成，则其任务时限应设置为1天。如果一项任务需要一个人8个小时才能完成，则其任务时限应设置为2天，以此类推。

半场工作制有两个假设的前提：第一，我们的团队成员来自不同的部门并且同时承担其他项目；第二，事情不会100%按照计划进行，这意味着可能会出现障碍。将团队成员的时间安排为仅占用可工作时间的50%，可以将剩余的50%工作时间用于解决计划外的可能障碍或风险。

我们相信，快乐且高效的项目团队成员可以产出非常有效的成果。而倡导并确保我们的客户利益相关者不会过度压榨我们的团队成员，是我们身为管理者的责任！

8. 责任人、开发人员和用户要能够共同维持其步调稳定延续。

我认为这个原则意味着我们对项目推进的节奏应抱有现实和人道的期望，即每周大约40小时的工作，不多不少刚刚好。因此，责任人、开发人员和用户将能够共同维持项目进展的节奏，且不会导致相关人员的过劳。我们通过下面几个方法来确保这一目标的实现。

首先，我们制订工作计划，将任务分解为不超过12小时的增量。这使总体进度/项目进度表的任务持续时间得以具化。当一项任务只需要12个小时或更少的时间就能完成时，完成它所涉的步骤清晰可见或很容易解释。我们使用项目管理标准中的其他工作计划原则，来确保工作计划可以作为有效的沟通工具。

其次，我们将完成的工作计划用来细化完成整个项目及其各项任务所需的具体时间。这确保高层管理者利益攸关方人员不能任意要求提前完结项目，因为这可能需要英雄因素。我们将英雄因素定义为团队在晚上和周末加班加点，以按照计划交付或玩命冲刺。

有了数据翔实合理的工作计划，高层管理者利益攸关方人员将获得所需的信息，来接受既定时间安排、缩小工作范围或在需要延长项目周期时向上级申请的理由。

此外，我们还将小组成员的每日工作量限制为仅占用可工作时间的50%。这样他们可以将剩余的时间花费在项目之外的活动上，也有灵活的时间可以解决障碍，从而无需英雄因素（晚上和周末加班加点）。

最后，我们培训项目团队成员及其经理，如何使用工作计划中的信息来确定他们在整个项目组合的活动优先次序。我们还教会他们的项目经理，如何使用相同的信息来确定团队的工作任务什么时候过量了。有了这些信息，项目经理就可以在项目进度落后之前，推迟任务的完结日期或有充分的理由要求增派团队成员，从而消除对英雄因素的需求。

9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

归根结底，糟糕的工作意味着返工，这会影响到项目团队尽可能频繁地创造价值的能力。如前所述，项目经理的工作，是确保项目利益相关者的成功，这就包括充分高效地利用时间和资金。我们的项目规划方法，要求项目经理充分理解为什么领域专家确定的每个任务都是必要的。这使项目经理可以挑战/批评领域专家建议的管理方法，也杜绝了走捷径的可能性。此外，还可以确保工作始终能够满足客户的期望。毕竟“做错”等于“没做”。

10. 以简洁为本，它是极力减少不必要工作量的艺术。

我们再次强调， 120VC项目管理标准是原有标准的优化版，能确保我们的客户可以充分利用每年划拨的资金，尽可能完成其投资组合中更多的项目。我们针对每个项目的定义、规划和审查合理可行的工作计划的管理方法，可确保我们仅完成交付客户利益相关者所需价值而必须完成的最少任务。审查过程还可以确保采用最简洁高效的管理方法，并且不会以次充好地交付客户所需的价值。

11. 最好的架构、需求和设计出自组织团队。

在项目管理方面，项目经理只是领域专家。因此，我们的项目管理方法尊重其他领域专家的存在并依赖他们的专业知识。项目经理的职责是确保每个人的才能和专业知识得到充分利用，从而为所有项目利益相关者取得最大的成功。因此，项目经理从不对项目团队成员提出任何强制性要求。

工作的方法、任务的设定以及障碍的解决方案，均由项目团队成员和合适的领域专家确定。项目经理的工作是促进这些讨论；通过提问确保整个团队清楚了解障碍的定义；并帮助每个团队成员对自己的承诺、职责和专业知识负责，以确保团队中的每个人都发挥自己的潜力。

12. 团队定期地反思如何能提高成效，并依此调整自身的举止表现。

每周，项目经理都会与整个项目团队举行一次会议。该会议包括：每周一次的站立会议，团队成员在站会上提供有关其当前任务的最新信息；冲刺计划会议，团队在该会议上审查在下一个冲刺中拟开始的工作；会后讨论，仅限必要的团队成员参与，主要探讨解决障碍的合作方案。

在会议的冲刺计划部分中，在即将开始的下一个冲刺中承担工作任务的每个团队成员，都应使用“检查-适应”的模式，来考虑下列问题并汇报答案：

第一，基于目前掌握的信息，有没有更好或更快速的方法来完成计划的任务？

第二，计划的任务仍然有必要完成吗？

第三，开始计划中的任务有任何障碍吗？

随着项目每日推进，项目经理和团队对完成项目所需和不需要的内容会更加明确。每次团队会议对当前状态进行总结汇报并为障碍提供解决方案时，都需要完善工作计划，以确保其匹配这些会议中做出的决定。这应该至少每周开展一次，并成为项目经理的常规工作。对既定成本或进度产生负面影响的变更，将采用规定的检查过程予以评估和处理。项目负责人对这些变更进行评估，以确定其业务价值。如果项目负责人批准这些变更，则更新后的工作计划将成为新的基准，相当于更新后/优先级较高的产品待办事项列表。