用敏捷思维做中大型项目1-敏捷理论基础

互联网行业有一种说法，叫做“敏捷已死”。事实上，不是敏捷已死，是很多项目用着用着就偏离了敏捷的思想和原则，甚至走入了误区，不仅没有发挥敏捷本身的效用，更是给组织，给项目带来了很大的困扰。

今天，就个人的理解，来聊一聊用敏捷思维做中大型项目。

用敏捷思维做中大型项目1（敏捷理论基础）

之所以说是用敏捷思维，是因为，敏捷思维其实在我们的工作生活中无处不在的。比如最常见的，我们去餐厅吃饭，我们点了10个菜，餐厅是一个菜一个菜持续交付的，并不是等到10个菜全部做完后才统一上菜。这个过程中，也经常会出现，更换其中的某个菜，或者退掉某个菜。那餐厅要服务好客户，就得拥抱变化，合理满足。

而我们实际开展一个项目，大多数的时候并没有真正套用敏捷的某个方法论，比如最常用scrum方法论（占有率66%：数据来源于2021年7月发布的敏捷报告）。

那么在正式开始介绍用敏捷思维做中大型项目管理之前，我们还是先认识一下什么是敏捷。

一、认识敏捷

1、敏捷宣言

敏捷宣言诞生之后，其包括4个价值观和12条原则，以及一系列的敏捷实践。

敏捷是一种心态，这是敏捷的核心，是一种基于敏捷价值观、原则及实践的心态或做事的思维哲理。

所以，从这个维度来说，敏捷并不是某种特定的方法论、过程、架构或工具。

敏捷真正告诉我们的是要以敏捷心态、敏捷思维来做项目，做事情。

2、敏捷4个价值观

我们知道敏捷宣言包括敏捷4个价值观：

个人与互动胜于过程与工具

可用的软件胜于复杂的文档

与客户协作胜于合同谈判

响应变更胜于遵循计划

我们可以看到这其实是分成了左右两部分，右边的过程与工具、复杂的文档、合同谈判、遵循计划，也是有价值的，但相比较而言，左侧的个人与互动、可用的软件、与客户协作、响应变化则更有价值。

3、敏捷12项原则

敏捷12项原则。

原则指导行为。其他的都可以裁剪，唯独原则不能裁剪，可见原则的重要性。

也就是说，要运用敏捷，就需要遵循这12项原则。

1）我们的第一优先任务是，通过尽早且持续交付有价值的软件来满足客户。这是使用敏捷的目的，尽早交付、持续交付，让客户满意。

2）即使在最后开发阶段也要竭诚欢迎改变需求，敏捷过程掌控改变，以维护客户的竞争优势。我们的态度就是拥抱变化。尽管尽早交付，持续交付可以降低风险，但也很难预测未来，当发现按原计划执行下去的时候无法替客户创造价值，就要欢迎改变，团队拥抱变化。

3）经常交付可以的软件，频率可从数周到数月，以较短的时间间隔为佳。关注的重点是交付客户需要的软件，所以，尽早且频繁的交付，交付频率1-4周，最好不超过6周。

4）业务人员与开发者在项目进行中，必须每天一起工作。合作共赢，业务人员和开发者在项目进行中时，可以频繁的沟通，通过共享彼此的想法、文档和解决方案，对齐目标和需求。

5）项目靠积极的个人来完成，给予他们所需的环境支持，并相信他们可以完成工作。核心还是人。要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。项目成功最重要的因素是人。

6）在开发团队与团队成员之间，面对面的沟通是传递信息最有效率与效能的方式。最优效的沟通，是面对面。所以，敏捷团队大都是集中办公。

7）可用的软件是进度的主要测量标准。衡量进度的标准就是交付可用的软件。

8）敏捷过程提倡稳定持续的开发，发起人、开发者及用户都应该能不断地维持稳定的步调。虽然我们的态度是拥抱变化，但并不代表着可以随时随地的进行变更。项目方、开发人员和用户应该能够保持恒久稳定的步调，持续交付可用的增量成果，既不过渡疲劳，也不过渡空闲。

9）对技术的精益求精以及对设计的不断完善将提高敏捷性。所有团队成员都应持续专注于追求卓越，团队协同工作的平台和工具也都要随着时代的演进和精进，让团队更有效率和效能地完成项目。

10）简洁，即尽最大可能减少不必要的工作，这是一门艺术。根本的原则是简洁，不做过渡和华而不实的设计。比如我们很多电视的遥控器，其实大部分功能是没有用的，你看看小米的电视遥控器，就几个主要按键。

11）最佳的架构、需求和设计将出自于自组织团队。敏捷团队是自组织团队，团队成员共同解决项目中所有问题，每个成员都具有项目所有方面参与权，共同承担职责。

12）团队要定期反省怎样做才能更有效，并相应地调整团队的行为。敏捷团队是要不断的改进开发成果的方式，复盘总结经验。

4、敏捷的定义

前面我们介绍了敏捷的核心，4个价值观和12项原则，那我们给敏捷下一个定义。

敏捷是适应“互联网+”时代的一种思维方式，是一种心态，一种基于敏捷的价值观原则跟实践的心态，或者是做事情的思维哲理。

敏捷是创造并响应变化，从而在动荡的商业环境中创造利润的能力•敏捷是平衡灵活性和稳定性的能力。

敏捷不只是交付（产品/功能），而是发现（价值）

所以，我们常说的敏捷不是流程，也不是方法，而是一种适应时代需要的思维方式，是一种为产品创造最高价值的心态。

二、传统与敏捷方法论

1、传统软件开发方法论

传统软件开发方法论，通常指的是预测型，是属于完全计划驱动型生命周期。

1）管理方法

•早期完整计划，可使用滚动式规划

•顺序或交叠的按计划进行

•各阶段工作有不同的性质

•各阶段项目团队结成与所需技能不同

2）适用场景

•适用于充分了解拟交付的产品

•行业实践基础厚实

•整批一次性交付产品有利于相关方

3）开发模式

传统软件开发模式是一种瀑布式的模式，从下图也可以很好的理解。

2、敏捷方法论

1）敏捷方法论概述

我们所熟知的敏捷方法论，包括scrum、XP、看板、精益、水晶、DSDM等

其核心价值大都是客户导向、价值导向、消除浪费等。

3、传统和敏捷的比较

传统项目是铁三角，范围、时间、成本，包括质量，组成了四要素。

下图左边的三角形。传统项目是以计划为导向的。

而敏捷项目三角是价值、质量、约束。如上图右边的三角形。

价值：可发布的产品

质量：可靠、适应性产品

约束：成本、时间、范围

考量指标是价值（向客户交付价值）

质量（需要向客户交付可持续的价值）

约束（范围、进度和成本）。约束仍然是重要的项目参数，但不是项目的目标。在敏捷中，价值才是目标。

为了提升客户价值，这几个约束可以随着项目的进展适时作出调整。进度可能仍然是一个固定的约束，如果是那样的话，范围就可以调整为在固定的时间期限内向客户交付最有价值的产品。如果要有适应性，就必须牺牲或调整一些约束为代价来实现价值或质量目标。

再举个例子来说明下，传统和敏捷的比较：

比如传统开发为期一年的项目，下图已经比较形象的展示出来了，项目从启动之后，需求准备，设计，开发，测试，到最后发布，或交付给客户都是将所有的事情做完之后才到下一步。这样一来，会大大增加最后交付产品的风险。

而采用敏捷思维，开发为期一年的项目，参考如下图，从项目启动之初，就是持续的交付，每次交付优先级最高，价值最高的系统，然后获取客户的反馈，并根据商业价值调整待办列表（或者是优先级）。过程中，如果有不满足客户需求的，就及时沟通调整，最终到项目收尾的时候，交付让客户满意的项目。

更详细的说明，在PMBOK指南第6版里面是有详细介绍的，参考如下图：

4、敏捷的使用范围

用敏捷思维做中大型项目（中下篇）将会为两个大部分：

一、敏捷项目管理概述

二、敏捷项目管理实践

重点是敏捷项目管理实践，将重点围绕整个敏捷项目管理框架，从立项-启动-版本循环-适应变更-迭代循环-交付最终产品-收尾全过程，届时会详细介绍每个阶段怎么具体去实施。

本文来自公众号：项目管理跃迁（ID:xmglyueqian），

作者：徐州，鹅厂项目经理一枚，PMP，PRINCE2，专注于分享日常项目管理过程中的点滴，辅以分享职业成长的思考与感悟。著有《谁说菜鸟不能成为项目经理》一书。

授权发布于管理圈，如需转载请联系原作者。