敏捷是什么？为什么要使用敏捷项目管理？

分享嘉宾：大懒

大家晚上好，有幸接受这个邀请，去给大家说一说，就是关于敏捷的事情，敏捷这点儿东西呢，我其实也是一个失败者。但是呢，在失败的过程里面也找到了一些正确的方法，希望能通过这个机会呢，把更多的信息告诉大家。

1、什么是敏捷

很多老板在选择用怎样的开发模型去开发，特别是开发软件的时候，总有这样一个误区。我们使用了敏捷方法之后，可以更快的去交付产品，可以缩短产品研发的生命周期，可以节省成本。这个理解是有偏差的。

首先给大家说明这个问题，敏捷不一定会很快。

为什么不一定会很快呢？假设我们是一种迭代开发的模式，我们用很多的迭代去开发同一个产品，大家想象一下，是不是每一个迭代里边都会有一个小瀑布呢，那么在每一个迭代里面的测试，开发，设计，这些环节是不是都要重新再来一遍呢，所以说敏捷，它不是一个能够更快交付的模型，而是一个能够更频繁交互的模型。

第二，敏捷不一定会节省成本。

其实明确的说，敏捷这件这种行为是非常昂贵的，这与他的研发模式和行为方式有关系。待会讲到敏捷需要一个什么样的团队，敏捷会需要什么样的测试方法，或者是成本核算方法。包括风险识别方法，包括需求控制的方法，对这些方法的使用过程里面可能会产生额外的成本。而这些成本会造成敏捷的成本相对增加。

但是呢，敏捷不是为了节省成本和快速开发缩短开发周期而诞生的。

2、为什么要使用敏捷

我介绍一下这个敏捷模型，这个模型能很好的告诉我们，为什么要使用敏捷去解决问题。

这个东西就叫Stacey矩阵，或者叫Stacey模型。

这个模型里面分四个部分，一部分叫Simple，just do it。第二部分叫Complicated，然后空白的部分叫complex，右上角那个我把它叫混沌，混沌的问题咱们不去讨论，实际上我们在软件开发里面，要做的事情就是三体里面讲的，叫降维打击。

在这个过程里，我们将复杂的东西划到一个相对简单的区域去解决。然而呢，对于一些很复杂的情况，比如说，我们需求很不确定，我们也不确定用什么方法去做这些事，我们就用敏捷方法去做。敏捷方法是什么呢，就是持续学习，持续迭代，持续规划这样一个方法。

这是一个实用的非预定义过程。

有同学问，敏捷项目和传统项目的区别，如何进行混合应用，相互取长补短？传统项目即预测型项目。

我们在预测性的项目里，做的事情是这样的。首先有一个发起人，然后我们做一个详细的计划，然后强制团队，或者说责令团队按计划去进行，然后在中间控制变更，按规定测试，结项等等，最后交付产品。

然而，敏捷不是这样的，一个敏捷软件的开发往往在敏捷初期，是不会预见到几个迭代之后的软件需求的。它往往是，以最小可行性产品，MVP，去交付给客户。也就是说我们用最基本的模型，最基本的能用的东西给客户去用，从而不断的得到客户的反馈，不停的迭代，改进，或者重构。这就是拥抱变化，或者叫检查和适应，敏捷和传统项目的一个比较好的区别的诠释。

所以敏捷，其实是一种轻量型的，最开始确实是用在软件上的，软件开发原则。它是一种方法，一种思想，是一种迭代的研发模式，而且是增量的，是一种一定时间盒的，以价值为中心的。

敏捷是一种适应复杂情况、不靠谱客户的，一种持续学习，持续增量的迭代模型。

敏捷有一个特别著名的东西叫做敏捷软件开发宣言，这个当时在2001年发布的时候，推动了硅谷的一个改革。

http://agilemanifesto.org/iso/zhchs/manifesto.html

敏捷宣言里面提到了四点价值观，这四点价值观大家看看就行了。他最重要的一句话，尽管右向有其价值，我们更重视左向的价值。说白了就是，你一切从客户出发，一切从变化出发，一切从成果出发，一切从价值出发，比你那些花里胡哨，按规定来的这些东西，更有价值。

它是一种价值观，也代表了这一帮人的一种处事方式。

3、 敏捷Scrum框架

下面介绍一些敏捷的方法，因为它是一种价值观，是一种思想，所以说有很多大牛，开发了一系列敏捷框架。

目前有有记载的，著名的敏捷框架有30多种，非著名的那可能好几百种都有。今天主要介绍就是那朵云彩，Scrum框架。

Scrum框架是在当今的软件开发界里面应用得比较广的一种框架，也是国内能看到的，大多数的敏捷在线项目管理工具的范本。

目前这个框架呢，有一个叫Scrum联盟的组织，在负责维护和管理。这个组织，每年会有一些认证，每年开一些会议，会定期地去更新这个框架。最新的这个框架A4纸打印出来只有27页。大家可以看到其实没有什么内容，里面写的就是一些原则和方法。

Scrum框架的思想来源于一个著名的思想叫精益思想，这个思想是丰田在上世纪80年代提出来的。这个思想有两个重点，一个叫，respect people，尊重人；另外一个叫Continuous improvement，也就是持续改进。实际Scrum框架也是秉承的这样的原则。

Scrum框架大概是长这个样子的。它里面有一个3355的原则，就是三种角色，三种工件，五个会议，五条核心价值观。

1.第一个"3"

左上角这三个圈儿就是我们所说的这个3355中的第一个3就是三种角色，在Scrum这个框架里面我们会给团队分配这三类角色，第一类叫Scrum master，不是一类啊，这是一个人；第二类叫产品负责人Product Owner；第三类叫团队，Team。

Scrum master在这里不是项目经理的意思，他更像是这个团队的保姆，他要负责整个团队的鼓励工作，为团队服务，给团队提供理论支持，引导团队。更像是教练的一个工作。

Product Owner是这个Scrum团队里边儿一个经过授权的人，他负责的是整个产品。整个产品开发做什么，不做什么，哪一部分在哪个时间点交付的这个工作，也就是说，负责构建产品待办列表。

在Scrum里头，这个团队是近似于全功能的跨职能团队，其实敏捷对团队的要求是非常高的，这也是他成本高比较贵的原因之一。

举个简单的例子，我们可能会在敏捷团队里面要求产品开发人员去编写测试用例，甚至是去执行这样的测试用例。甚至是我们测试人员也要去写这种行为分析用例，要写代码。所以说最理想的Scrum团队的Team，每一个人都应该是通才。

上面这一段就解决了“常用的敏捷架构是什么样的，团队是什么样的”这个问题。其实我觉得任何一个团队都有可能会去变去转化成自己的团队，只要你有合理的配置，然后一个足够能引导你进入敏捷开发空间的这样一个人就可以了。

2.第二个"3"

Scrum的3355的第二个3也就是三个工件。

①第一个工件，叫产品待办列表（Product Backlog），它其实有点儿像我们现在产品开发中讲的需求池的概念，通常来讲，我们会把所有需求一股脑的扔到这个列表中去，但是这个列表会有一个与传统的需求池不一样的地方。这个列表里面所有的需求，都是有价值的，有次序的。

②通过我们价值的体现，包括我们对它的排序。我们就会得出这样一个结论，我们应该先做什么，后做什么，于是就有了第二个东西，我们叫做Sprint backlog，这个东西，翻译成中文就是冲刺待办事项。

③然后我们看第三个工件，在那个大圆圈右边儿，叫潜在可交付产品增量，这个东西大致的意思是，我们在做产品的时候，是一个迭代增量的过程。

比如说我的需求是通行，从A地到B地，我们传统的做法是定一个需求，这个需求可能会很大，比如造一辆汽车去进行通行，通常在传统里面，我们会先造一个轮子，再造一个底盘，然后再造一个壳儿，再往里面填充起来。

但是对于敏捷来讲，不是这样操作的。增量交付一个很好的例子就是这个通行问题，我们先造一个滑板车，先能满足这个用户的需求，然后我们再造一个自行车，更加的便利。然后我们再造一个摩托车，最后我们再造一个汽车，最终交付给客户。

从这一点上我们来看，这个敏捷实际上在交付用户的使用价值，或者说在交付用户的价值。

3.第一个"5"

我们在这个敏捷里边儿有五个会，

①第一个叫Scrum计划会议，把产品待办事项列表里面的东西决定哪些可以在Scrum计划会议里边儿解决掉。

②第二个会议，我相信很多的企业，很多的团队在做，叫做每日站会。

这个站会通常都问什么问题呢，我昨天做了什么，今天我要做什么，我遇到了什么问题，通常都是这样的对吧。但是我想告诉大家的是，大多数团队开这个会的时候，问的这三个问题都是不正确的，我们去看原文：

第一个问题：What did I done yesterday that helped the Development Team meet the Goal?

第二个问题：What will I done today to help the Development Team meet the Goal?

也就是说在敏捷开发这个环境里面，我们不会讲我做一件事情，做了百分之多少，在敏捷的世界里没有百分之几这个概念，它只有零和一。没完成就是零，完成了就是一。所以他的问题会说，我为了我们团队的目标，昨天做了什么；我为了我的团队目标，今天我要完成什么。

③第三个会议叫做Sprint评审，Scrum review。这个会议就是来评价你迭代的这个产品，是不是可以纳入到潜在可交付的产品增量，这还是个潜在的，还是不可交付的，经过了这个会，你能不能交付这个事儿就能定了。

④第四个会议叫Scrum回顾。希赛发过一篇文章，里面有一部分讲回顾（文章后附该篇文章的链接）。那就是敏捷回顾的一部分，叫做帆船工作法，或者帆船回顾，有兴趣可以翻回去看一看。敏捷回顾对敏捷这种活动来讲是非常重要的，应该说是在这几个敏捷Scrum的活动里面是最最重要。通过回顾，我们不但能够找到过去的一些缺点和失误，还能发现一些优点，并持续的改进下去，这对于敏捷团队尤为重要，为什么呢，因为敏捷这件事，第二个原则就是要持续的改进。

⑤第五个会议是一个持续的活动，这个活动叫产品列表梳理。说白了就是收集需求。因为敏捷相对于传统开发，这个需求不是那么稳定。但是我们讲拥抱变化，我们拥抱变化，不是为了让需求蔓延。拥抱变化，也不是为了让项目镀金，拥抱变化的意思是要让项目符合用户的价值，要让项目达成既定的目标或持续改变着的目标，我们要对这个需求做调整，这件事才叫拥抱变化。

4.第二个"5"

对于Scrum来讲还有五条价值观，专注，公开，承诺，勇气，尊重。

4、敏捷实践

另外给大家介绍一下敏捷实践，敏捷实践是很有意思的，其中有一个叫结对编程，是极限软件开发里面的一个活动，两个人用一台电脑去编，一个人写，一个人看。

这个事儿从敏捷的角度来讲，是一个代码review的过程，实际上是替代了代码评审。

但是同时还有一个更大的价值，我们把一个初级工程师和一个高级工程师放在一起，这两个人的水平会无限趋近，水平低的会往水平高的趋近。

Scrum指南的网址有很多版本，大家可以去下载看一看。https://scrumguides.org/

5、QA

Q：敏捷这一概念是否像咱们群的口号一样：一切皆项目，是否敏捷这一概念一切都适用？

A：这个不尽然，因为，就比如说我们学PMP^®，有个事业环境因素，意思就是每一种情况，都不一样，团队也不一样，项目也不一样，实际上我们现在有很多的很多敏捷框架，好像可以解决各种各样的问题。在敏捷开发的早期，布道的老师们包括敏捷宣言的翻译者，给人讲课的时候，他说敏捷可能会适用于产品开发项目和小团队开发项目。所以说最初的Scrum文档里头，他会讲你的团队规模要保持到七加减二。

为什么是七加减二呢，因为这个是有一个临界值，大家学过沟通管理里面团队沟通的项目公式N*(N-1)/2。所以七加二，正好是一个临界点。但是对于现在的项目来讲，使用小团队，小迭代已经不能满足很多企业的要求。比如说，网易阿里腾讯，大家都在用敏捷的方法开发大型项目。所以现在有很多的敏捷理论，比如说LeSS啊，比如说SAFe啊，这种理论会支撑着他们去做大型项目的敏捷。

敏捷团队有个行为叫自组织，就相当于团队七个人，每个人都是项目经理，每个人都是干活的，每个人都是测试，每个人都是各种各样的角色。所以说对于敏捷这件事儿来讲，质量是由整个敏捷团队来负责，不是有哪个人去负责，成果也是有整个团队去负责的。

Q：敏捷项目如何做到过程文档规范？

A：这个事情我给大家讲一个故事，我们在第一次CMMI三级评估的时候，我们把快速模型，也就是敏捷基于Scrum模型的方法融入到了CMMI的方法里面，然后对它进行文档规范化。但是这件事儿呢，失败了，失败的原因第一个团队问题，第二个就是他与当时的CMMI一些理念，是有冲突的。

那么，对于文档规范化的问题呢，敏捷里面有一个这样的思想：我们所有的敏捷开发团队都应该有一个信息源。这个信息源应该是所有敏捷团队成员及其相关的所有成员，包括你的领导们，都能看到。信息源上应该有项目里面的能够展示的所有信息。

我举个例子啊，如果非要把过程文档化，我的建议是用系统去做，一个管理系统去做，用看板去做，然后呢，不要太追究这个形式，要看你文档规范化管理的目的是什么，是要管控流程，还是要管控某一件事儿，所有的这些东西在信息源上做相应的展示就可以了。

Q：敏捷项目和传统项目的区别，如何进行混合应用，相互取长补短？传统项目即预测型项目。

A：这个是很多团队，包括我在内也在不停研究的一个事儿，我的观点是这样的，我们适当的在团队内推行一些敏捷的行为和活动，从而引导团队去用敏捷的思想。或者说相对敏捷的思想去思考问题，在团队层面上先建立一些敏捷或者敏捷行为的习惯。

当然，在这个过程里面可能会比较痛苦，可能会造成效率的下降，但是这是敏捷转型的一个必经阶段。在敏捷转型中，授予团队的首先是行为，然后是理论基础，然后再是架构和方法。我觉得这样推广比较好，团队也能很严谨，比较能够接受。

Q：敏捷项目中的风险如何识别和把控？

A：首先从传统意义上来讲，这些风险的来源在哪儿，作为一个项目来讲，我们风险来源无非就那几项。首先你的风险来源肯定会有一个历史数据的风险对照表。

那对于敏捷来说，这是什么呢，还记得我们敏捷有一个回顾活动吗，在回顾活动中，我们会识别一些阻碍，会识别一些暗礁，不知道暗礁是什么同学，可以补个课https://mp.weixin.qq.com/s/wvnw56ENY0wHYLkUM6yd2Q

这是其中一个来源，另外一个来源呢，我们之前讲了敏捷有个sprint计划会议，在计划会议里面有很多活动，其中一个活动，就是讨论需求的价值。因为敏捷活动需要交付价值，我们在需求层面上要充分讨论需求的价值，那么需求的风险会降到，怎么说呢，需求变动的风险其实很大，但是他可能会降到零概率。

然后就是一些其他风险来源，比如说人的风险，设备的风险，资源的风险。。。这些风险，应该是能在团队内部消化的。对于控制这样的风险，作为一个敏捷团队来说，应该自己能够去识别，能够去控制，而且能够在会议里面解决掉。

站会要提三个问题，第一个问题：what did I done yesterday；第二个问题：what l will down today；第三个问题：我遇到了什么样的阻碍和困难。

Q：敏捷项目里面有哪些活动是可以推广的？

A：最简单的就是站会，另外一个觉得比较值得推广的就是用户故事和用户故事地图。

用户故事从根本上来讲就是一个需求，就是作为一个什么样的用户，需要一个什么样的东西，以解决我什么样的问题。对于敏捷来讲，他的需求是有一个invest（要求）的，看下图

用户故事有一个3C原则，第一个叫card，也就是说写在卡片上；第二个叫conversation，对话；第三个叫confirmation。它实际上是写在卡片上，用来激发产品或者需求讨论，从而达成各方一致的行为。

用户故事实际上就是这个用户行为的一个集合，就像这张图里面，左上角是一个客观条件，是一个人物画像，女人30岁，一条狗。然后她起床会做哪些事儿，洗漱整理会做哪些事儿，照顾家人会做哪些事儿，然后哪些事儿是按顺序做的。这对于用户行为需求一样也适用。

我们拥抱变化的同时，我们就要去适应这种变化的发生，在这个时代很多不确定因素会使你的需求变得越来越不稳定。

作为产品经理，你的责任是尽早的去识别变更。而作为研发团队，你的责任是需要使用更灵活的框架，或者不断的减少你的技术债，去适应这样的变化。

Q：敏捷项目如何估算确定项目交付期？

A：通常来讲，我们做传统的估算，无非就是经验估算法，Delphi估算法，功能点估算法。我们估算出来的结果是一个绝对的值，也就是说，我估算的东西，要么是我工程的规模，要么就是完成这个工程使用的工作量（人·天）。

但是对于敏捷来说，通常来讲估算的都是故事点，或者说是一个相对的变量。我会在一个敏捷团队的内部定义一个叫“1”的东西作为一个标杆，然后针对这“1”去做相对估算。

比如说我有一个“1”，我有一个功能，可能是1.5，可能,2，可能是4，可能是8，通过这样的估算，我们能估算出来我这一些的需求，这一堆的故事需要几个“1”。

在迭代的初期，我们会试着把几个这样的东西放到一个迭代里头，通过迭代的不停的迭代，两个，三个迭代之后，这个“几”能够放在迭代里头的这个“几”，就相对稳定了。可能我们第一个迭代能做八个，放了十个进去，我们只做了八个；第二个迭代我们只往里放八个，我们发现八个相对也挺高，我们只能做七个；第三个迭代我们做了七个，第四个迭代我们也做了七个。那么，这个团队的迭代速率就是七。

那对于一个稳定的敏捷团队来说，你知道了你的速率是多少，同时，你也能知道你产品规模的这些点是多少，那你的交期就可以确定了。

Q：敏捷项目如何快速、准确评估项目预算？

A：我们用的敏捷估算方法都是很好玩儿的方法，比如说有扑克估算法，T恤估算法，大小杯子估算法等等。

这种敏捷估算扑克是专用的，在网上可以买到。第二个叫T恤估算法，就是用大小来估算，具体方法比较复杂，大家有兴趣的可以去查一查。

话说回预算的问题，对于敏捷团队来讲，不会做一个初始的预算，规定我的预算是多少，通常来讲，我们在项目的初期会订一个预算目标。这个目标是一个用经验值来做出来的，或者大家共同认同的一个目标。

那你在敏捷迭代活动中或敏捷开发活动中，你的所有活动可能就要围绕着这个目标去做。

Q：敏捷开发的缺点？

敏捷开发的缺点很多，我挑重点的说。

①敏捷开发对于某些团队是绝对不适应的。比如说，一个临时的团队，敏捷团队最好是相当的稳定。如果我的团队里面有个人很不稳定，他随时都可能会离开。那么这个团队就不适合做敏捷，甚至说我觉得应该把这个人提前踢出团队，再去考虑敏捷这个事情

②然后敏捷对团队的要求是非常高的，首先这个团队里面所有人都得水平相当，然后所有人的沟通能力和协作能力都要非常强。

③另外呢，就像刚才一同学说的，如何做好敏捷文档规范化。敏捷宣言里面有句话叫，使用的软件胜过详尽的文档。敏捷对文档的规范化或者文档的作用，看得不是太重，但是实际上它是有一定的文档规模的。但是就是这个文档的不完善，对新加入敏捷团队的人是一种挑战，还是刚才那个稳定性问题。

文档的缺失实际上会给后期的维护，二次开发等等带来一定的困扰。我会建议团队去单独抽出一个人去做这些事情。

④还有一个缺点就是，我见到的大多数敏捷团队都有冗长的技术债要还。就是因为没有一个足够灵活的软件框架来适应足够多的变化。

⑤最后假设我们不断给用户交付用户觉得有价值的产品，这个时候用户是持续满意的。反之如果我们交付的是用户不怎么喜欢的产品，用户是不是就持续不满意了。实际上用户持续不满意，还是有去改进迭代的空间。但是我们要考虑到不满意是因为技术债，还是因为质量崩塌，还是因为团队不稳定，还是因为需求等等。

⑥很多的敏捷团队还会产生质量崩塌的情况，从质量来说，我还是觉得传统的方式比敏捷的要好一些，因为他的管控力度，包括过程管理，结果验证这些东西，还是比较好的。

但是敏捷在质量中还是有一些办法的，下面介绍几个跟质量相关的工具：

第一个叫TDD，测试驱动开发，就是先写测试用例，然后再写代码，然后找到一个比如jenkins那种的持续集成工具上跑一下你的测试用例。

第二个叫行为驱动开发，这个通常来讲是有测试人员去做，行为驱动开发一个比较好的工具，叫cucumber（黄瓜）。它是一种以用户为角度的行为测试工具，这个去迎合和测试业务场景是非常好的。

Q：采用传统瀑布模式开发的项目可以敏捷吗，怎么操作？

A：先行为导入，然后知识导入，然后再价值导入，然后再知识导入，这样一步步潜移默化的去改变他们的行为方式。

瀑布模式开发的项目可以敏捷吗？这个东西也不尽然，这个得看项目类型和团队行为方式。如果一个企业，一个团队想做这种敏捷转型，我的建议一直都是你去找一个专业的教练帮助你去做，不要自己看本书就做，很多敏捷转型因为这个失败，这个很容易失败。

Q：今后敏捷是否更受企业的青睐？

A：不仅谷歌微软在用，国内的大厂也都在用。这个就没有什么讨论的了。

6、看板

补充一个看板的知识，看板这个东西其实也是挺重要的，在如果有同学学PMI-ACP^®，PMI-ACP^®推荐的书有一本就是看板。

看板就是我发的这张图，这就是一个最简单的看板。看板有两个作用，第一个作用叫价值流动，第二个作用叫限制在制品。

看板就是每天在开早会的时候，把各个工作改一改状态，就是这么简单的一个事情。看板其实做了敏捷中的很多事，它起到了信息发射源的作用，也就是说，团队中的所有成员都能通过这个看板看到这个项目的进度和项目实时的情况，而且能够知道我在这个项目的哪一列上，或者说在哪一个状态上有迟滞了。

有兴趣的同学可以去看那本儿看板方法，里面讲的很详细。

最后分享一个看板实践这本书的读书笔记