深度解读敏捷思维与敏捷开发实践

一、如何正确看待敏捷？ 

1.对敏捷的误会

关于敏捷，许多人常常有这样那样的误会，比如一下典型的四类：

第一类：将敏捷与快速划上等号

敏捷开发就是快速开发

敏捷能够提高开发速度

使用敏捷，产品可以更快上线

使用敏捷，项目可以更快交付

第二类：

我们用的是敏捷，因为我们是迭代开发

我们用的是Scrum，因为我们团队每天都开站会

第三类：

使用敏捷，不用写文档

使用敏捷，不用做项目计划

使用敏捷，不用走流程

第四类：

需求不确定用敏捷，需求确定用瀑布

互联网产品用敏捷，2B项目用瀑布

看到这里的你，说不定已经中枪了

“敏捷难道不是这样子的？”

还真不是，

等你读完下文，

深刻领会敏捷的思维方式和含义后，

不妨再回来审视这些点。

2.对敏捷的争议——敏捷已败？

此外关于敏捷，还有一个长年不休的话题——“敏捷已败？”。

自敏捷诞生以来，几乎每隔几年都会出现一次有关这个话题的大规模讨论，在国外国内的敏捷教练圈里，人人都在发表自己对敏捷是成功还是失败的看法。最近的一次大规模讨论发生在2021年，而这一年恰好就是敏捷宣言诞生的20周年。

当我们谈论敏捷的时候，

我们在谈论什么?

说到敏捷，你真的有好好审视过这个词的含义吗？

敏捷的英文是Agile，翻译成汉语就成了“敏捷”，而这可能正是人们常常将敏捷与快速混为一谈的根源所在。与其翻译成“敏捷”，说不定翻译成“灵活”要来得更不至于引起误解。

下面我就用一个手游的例子，带你直观感受一下敏捷与速度的区别。

敏捷≠快速

 

这张图片来自一款叫作 NBAlife 的手游，是一张显示了球员各种信息、属性的球员卡。在这里我们重点关注速度（Speed）和敏捷（Agility）这两大属性。

可以看到，速度与敏捷这两种属性在这里是区分开来的，也就是说速度和敏捷其实是两种的概念，敏捷并不意味着更快的速度，两者没有必然的联系，比如请看下面的例子。

 

可以看到，在这样一张球员卡里，敏捷值比上一张降低了三点，但速度反倒还提升了一点，可见两者的确是不同的概念。

那么总结一下，

敏捷和速度有关，但它又不等同于速度。

“现在倒是明白了两者的不同，

但敏捷本身又究竟是个啥”

3.什么是敏捷

什么是敏捷，字典里是这样写的

Agility：敏捷性是一种是企业在无法预测、持续变化的市场环境中保持不断提高竞争力的能力。

还是看不懂？那再来看它的形容词形式

Agile：敏捷的，灵活的

这里的形容词也就是我们常说的敏捷了，字典上给出的解释是“敏捷的，灵活的”，那具体放到项目管理的语境下，它的意思就可以理解为：面对无法预测的持续性变化，我们需要主动去拥抱变化，拥有更强的适应性。

项目管理语境下的Agile：拥抱变化的，适用性更强的

在理解完Agile，我们进一步来看下面这三个概念：

Agile Development

Agile Team

Agile Project Management

Agile Development就可以理解成一种适应性更强的开发模式；

Agile Team就是拥抱变化、适应性更强的团队；

而Agile Project Management则是一种拥抱变化的、适应性更强的一种项目管理的方式方法。

二、如何理解敏捷的思维和原则？

1.敏捷开发宣言

2001年的冬天，齐聚在科罗拉多一处滑雪胜地的Kent等人，制定了软件行业历史上最为重要的文件之一——敏捷宣言。

 

几乎所有关于敏捷的入门课程，都会从敏捷宣言讲起。

这不仅是因为敏捷宣言是敏捷的起源，还因为它确立了敏捷运动的4条价值观：

个体及交互比流程与工具更有价值

可用的软件比冗长的文档更有价值

与客户的协作比合同谈判更有价值

对变化的响应比遵循计划更有价值

而更为重要的，是写在这四条价值观下面的一行小字：

也就是说，我们认可上述右边事项的价值，但我们更加重视左边的事项 

2. 左右事项的辩证关系 

敏捷宣言虽然更认可左边的事项，但也绝不否认右边事项的价值。

流程与工具是有价值的，文档是有价值的，合同谈判、遵循计划也同样是有价值的。

要是没注意到这点，就极容易陷入“敏捷不需要写文档”的误区。

敏捷的价值观不过是更加认可重视对变化的响应、客户的协助、可用的软件以及个体与交互罢了。

 3.四条价值观剖析 

捋清完左右事项的辩证关系后，四条价值观又有着怎样的具体含义呢？

3.1个体及交互比流程与工具更有价值

在我们传统的计划驱动的项目管理过程当中，充斥着大量的流程性东西。比如评审流程，项目立项的流程等等。但在敏捷看来，彼此互相的沟通其实更加有价值。

3.2可用的软件比冗长的文档更有价值

在一个项目开发的过程当中，我们更加重视及早地产出用户可以试用的软件，所以我们所用的各种各样的方法，不管是Scrum的方法，还是极限编程的方法，都是出于这样的目的。

3.3与客户的协作比合同谈判更有价值

在对接一些外国公司的项目时，和客户的协作时间比例往往比较大，软件交付最终呈现的效果也会比较好。

而在国内，许多客户普遍缺乏协作意识，在这种情况下，很多客户甚至会在项目结束之后才第一次看到软件，随即就开始觉得UI不好、软件性能也不好，就造成了大量的变和返工。

虽然国内这种协作意识淡薄的环境短时间内无法改变，但我们在项目过程当中应当思考通过什么样的手段和技术方法，来增强与客户的协助。

3.4对变化的响应比遵循计划更有价值

乌卡时代，具有敏捷思维的人欢迎变化、拥抱变化，面对变化可以及时做出响应。

做项目，最怕的是客户随时都有可能提出变更。事实上，变更无法避免，与其逃避苦恼，不如主动拥抱。

除了制定敏捷宣言，Kent一行人还发布了与敏捷相关的十二条原则。

前面提及的Scrum框架，以及各种各样的方法论其实都是对这十二原则的具体实践。

敏捷十二原则 

原则一 价值优先

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

这条原则秉持着前文谈及的敏捷的价值观，呼吁我们努力思考，尽早地提供有价值的软件给客户，使客户满意。

原则二 拥抱变化

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

当具备了一些敏捷的思维，掌握了敏捷的工具之后，一些突如其来的变更也算不了什么了！

原则三 短迭代交付

要不断的交付可用的软件，周期从几周到几个月不等，而且越短越好。

这条原则里同样包含及早交付的概念，但是更强调要把迭代周期缩短。

原则四 业务参与

项目过程中，业务人员与开发人员必须在一起工作。

正如前文所说，不管是客户，还是前台的销售或者售前的工程师，绝大部分情况下，在整个软件开发的过程当中，他们并没有参与进来。

这就需要我们想各种各样的办法，比如在敏捷实践过程当中，在一些场景里将这些业务人员，甚至是客户，带到团队里面来进行紧密合作，以保证交付可以达到客户的预期。

原则五 以人为本

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

这一条原则在Scrum框架里面体现的非常明显，在Scrum里边有一个角色叫Scrum master。

Scrum master最主要的工作就是挡住外界环境对整个团队开发的影响，让整个团队能够专注在一个迭代过程当中，完成所要交付的任务。此外，要以整个项目团队为核心，意味着我们额外重视整个敏捷团队的自组织、自管理的能力。

一个开发人员通常都是被动完成任务，没有主动地投入到项目中为客户创造价值。所以敏捷的一个核心价值观就是想办法激发所有成员的积极主动性。

比如说产品经理提供相关的需求时，只需要讲清楚客户想要什么，具体怎么做应该是由团队内部自行来做决定，并且将其实现。

原则六 面对面沟通

不论团队内外，最有效的沟通方法就是面对面的交谈。

敏捷团队或Scrum团队鼓励大家是坐在一起。

不妨回想下我们手头所在进行的项目，项目组里面的成员坐得远不远？好的敏捷团队就是大家坐在一起，抬头就可以进行沟通，而不是要在企微上。

企微的沟通效率比面对面沟通差一点，而邮件的沟通效率又比企微差一些 。所以，在敏捷团队里，我们鼓励大家坐在一起，面对面进行交谈。

原则七 成果导向

可工作的软件是衡量进度的首要指标。

传统的瀑布模型要求我们一步一步的进行项目开发。首先需要分析，再做系统的设计、开发、再做测试，测试完之后才得到一个可工作的软件。

而敏捷的做法则甚至是想让每一个迭代都能够获得一个可工作的软件。

原则八 保持节奏

敏捷过程倡导可持续开发。发起人、开发人员和用户要能够长期维持稳定的开发步伐。

Scrum框架会去设定2-4周为一个迭代周期。在整个项目开发工程中，迭代周期一旦确定，之后就需要保持相对应的节奏，不能随意变动，否则步调不够稳定，节奏感不强，开发人员就不太清楚版本的发布规律。

原则九 追求卓越

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

在整个项目期间要去追求一些技术、设计上的比较好的设计方式。

原则十 简单务实

要做到简洁，即最大可能减少不必要的工作，这是一门艺术。

在敏捷当中有一种叫作精益的方法论，目的就是减少一些浪费。

项目开发中的浪费实际上就是工程师的时间。工程师如果老是把时间耗费在一些不必要的工作上，无法对客户产生任何价值，那在敏捷当中就要尽可能减少。

原则十一 团队自组织

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

一个好的敏捷团队是自管理、自组织的，可以激发团队成员的积极性。

原则十二 持续改进

团队定期地反思如何能提高成效，并相应地协调和调整自身的行为。

Scrum框架里面有回顾会，即在团队中对刚刚结束的迭代进行一次回顾。做得好的就继续保持，做的不太好的，就寻找更优的解决方案。这种定期的反思会不断改进团队，提升项目交付的进度和质量。

以上就是所有从敏捷宣言背后延伸出来的十二条原则。

这些原则最重要的目的就是为了让我们的整个团队，不管是产品团队还是项目团队，能够尽早交付具有客户价值的软件。

并且敏捷当中的每一个工具和方法论其实都是对这些原则的具体实践。

现在我们一起跳出局部思维，俯瞰全局，全面深入地认识和学习敏捷。

三、 敏捷的“道、法、术、器” 

1.敏捷技术全景图 

道家文化的传承强调了“道”“法”“术”“器”四个字。

这是希望我们对事物的认识，不能只停留在表面，要深入内里，掌握规律，把握原则，了解方法和技术，掌握相关工具和环境。

敏捷思维，也是如此。

 

敏捷宣言属于一种敏捷价值观，属于“道”。

十二原则则是实现这些价值观的战略和方法，属于“法”。

“道”和“法”在前面已经介绍过了，下面我们来看“术”和“器”！

2.“术” 

“术”是行为和技巧。作为事物的中观层面，包含了各种技能、思维模型和分析模型。

在敏捷层面，也同样包含了一些方法论角度的“行为”与实践角度的“技巧”，将一些好用的模型充分应用了进去。

2.1方法论角度看敏捷“行为” 

Scrum 

Scrum框架如何运作，在下一期会进行具体讲解。

看板 

看板出自丰田，丰田的生产线会放置一个白板，工作人员就可以查看相应的进度。

目前看板已经十分普及了，在项目管理中，我们经常会使用电子看板。此外，白板也是非常好的工具，敏捷团队常用的一个工具就是白板加上便签，同样也可以实现看板的效果。

XP 

XP是Extreame Programming 极限编程的缩写。

XP主要是从软件工程的角度去实践敏捷的概念。

其核心思想就是：我们在软件开发的过程中首先要注重单元测试。有了单元测试之后，整个开发过程才能做持续集成，有了持续集成作为基础，我们才能对代码进行重构，而所谓的重构就是响应相应的变化。

优化性能的时候就需要进行此类重构，此外，需求发生变更时也需要对现有代码进行重构。

SAFe、LeSS 

SAFe和LeSS是两个常见的大规模敏捷的框架。

一个Scrum团队最好是7-9人，很显然一个7-9人的小团队生产力是有限的，如果我们面对的是一些大型项目，就可以通过SAFe和LeSS等等大规模敏捷的方法论来进行管理，更好地管理需求池、人员之间的协调互动。

DevOps 

DevOps是近两年越来越受到重视的一种方法。

如果从工具层面理解，DevOps则是一些做持续集成 、持续部署、持续发布的工具链。

此外，DevOps本身也在践行敏捷的价值观，正如在介绍XP时所提到的，我们只有有了自动化的持续集成，才能更好的对代码进行重构。对于开发团队而言的话，在效率上这会是一个极大提升。

2.2实践角度看敏捷“技巧” 

用户体验地图 

用户体验地图，也称用户旅程地图，是一个非常好的观察用户体验变化、收集用户路径的工具。

每日站会 

下一期会详细讲解怎么开好每日站会。

结对编程 

结对编程出自极限编程，指两个人在同一台电脑上进行编程。

从产出效率上来讲，两个人一台电脑的生产效率会比两个人两台电脑的生产效率低一些。

但好处在于，一个人在编码时，另一个人可以对代码进行实时的审查工作，很多时候，一些业务逻辑的写法可能需要两个人互相的碰撞才会有更好的解决办法。

TDD 

TDD 是测试驱动开发的缩写，同样也是在极限编程里非常推崇的一个方法论。

TDD 建立在单元测试的基础之上，这意味着在写任何功能性的代码之前，需要先把测试用例写完，再去写相应的功能代码。

功能代码写完后，若要确认功能代码是否正确，就需要马上去跑单元测试来进行验证。

持续集成 

持续集成是DevOps里一个具体的实践，是指每当我们有新的代码产出时，可以通过一种自动化的方式在服务器上进行构建、打包，进而可以发布到QA、UAT或者生产环境里面。

3.“器” 

“器”是提升效率的工具。在敏捷中，也有一些工具能将复杂的问题简单化。

 # 项目管理工具（jira、禅道）

工具的使用因项目而异，从软件开发的角度来讲，一般都会使用一些项目管理工具，比如说常用的Jira，以及在国内比较受欢迎的禅道。

 # 版本控制工具（GitLab、GitHub）

敏捷重视短迭代，所以版本的发布是非常频繁，甚至有游戏公司每天都会发布新的版本，所以必须要有一个好用的版本控制工具。

 # 白板、便签 

从物理的角度来讲，白板和便签都是非常实用的工具。

我们可以把任务写在便签上，把白板做成待办、处理中、完成等泳道，然后把这些便签贴到这些泳道里面，每天更新相对应的项目进度。

4.敏捷团队的特点 

在认识和学习了敏捷的“道、法、术、器”后，放在具体的实践环节，一个真正的敏捷团队应该具备哪些特点呢？

 

敏捷团队三大特点

 特点一：自组织自管理 

自组织管理在上文中的十二原则里提及过，是指当团队遇到问题的时，团队成员需要自己研究解决方案，自己解决问题，不需要领导的监督，实现自我驱动。

这听起来比较理想主义，但在实际的敏捷实践过程当中， 一个比较成熟的敏捷团队确实可以做到这一点。

体现为：一个commitment就是一个承诺，如果一个团队成员承诺八个小时完成某一项后端开发的任务，并且将其认领了，基本就不需要任何其他人去督促他了。这就是自组织和自管理。

尽管目前绝大部分团队都做不到这样的成熟度，但团队里的项目经理或是产品经理可以去思考如何激发团队成员的积极主动性，如何提升自主性和自管理性。

 特点二：完全透明 

团队执行项目时，每天在做什么、遇到什么问题、需要哪些支持，都是透明、可视的。

比如我们在每日的站会中，团队所有成员都需要更新自己的项目进展或提出协助需求，让团队之间能够了解彼此的任务及状态。

这不仅可以把控整体进展，也能在团队成员遇到困难时，那些有经验的成员可以主动、精确地提供帮助，降低功能开发的难度。

 特点三：自适应 

从对敏捷的解释里我们也可以看到，一个自适应的团队是可以响应变化的团队。

这个团队可能是在做产品，也可能是在做项目，不论是从产品经理来的新的需求，还是从客户反馈过来需要进行的变更，团队都能对相应的产品和项目进行反思，以适应新的这种变化。

另外值得一提的是对流程的回顾和反思。在Scrum敏捷团队中，很多流程是团队自己确定。如开站会的时间和流程，为什么“站会”不叫“早会”？这意味着每日站会不一定非要是在早上开 。只要团队内部协商达成一致，在合适的时间开就可以

这三个特点看似比较理想化，但正是因为具体项目中的变化太多了，使得团队必须具备这样的这种素质。

四、敏捷迭代和Scrum 

现在从“迭代”和“Scrum”2个方面来聊聊敏捷实践。

1.迭代开发  

在前文对敏捷的常见误解中提到，“我们是迭代开发，所以我们是敏捷的”，下面就用一个造车的例子来澄清这个误会~

 模式一 

 在这样一个造车的过程里，迭代1做了轮子，迭代2做了底盘，随后在迭代3做了外壳，最后终于在迭代4造出了整车。

 那这样的开发模式属于迭代开发吗？

可以看到，从功能的角度，这其实属于一种增量的开发模式。

就比如在软件开发中，四个月的时间里需要完成四个模块。我们就在第一个月做了第一个模块，第二个月做了第二个模块，第三个月做第三个模块，第四个月做了最后的模块，这就是一种从功能性上来讲的增量式开发。

 模式二 

相较于增量式开发，迭代式的开发更关注尽快地达到用户的预期。

 

比如说，用户的需求是一个从a点到b点的交通工具，按照迭代开发的模式，我们就可能会在第一个迭代做出一个滑板车来。

这个时候用户显然不大可能满意，毕竟用户想要的是一辆汽车，但是滑板车至少是一个交通工具，从可以从a点到b点。

在第二个迭代我们再优化升级，做出一辆自行车来，这比滑板车更轻松一点，速度更快一点。 

第三个迭代再进一步造出摩托车来，跑的更快，动力更强。最后在第四个迭代终于交付出一辆完整的汽车来，这就是迭代的开发模式。

比起增量的开发模式，这种迭代开发模式有着明显的优势。

在增量的开发模式下，前三个迭代里的交付物都达不到客户的需求，客户的预期只有在迭代四才有可能实现。

而在迭代的开发模式下，虽然第一个迭代中的滑板车达不到客户的预期，但客户能看到他在第二次迭代中有了一辆自行车；进一步到了第三个迭代有了速度更快的摩托车，就已经可以大大满足用户的需求了。

所以从客户满意度的角度以及更早交付的角度来看，迭代模式显然比增量模式更能达到客户预期。

在实际的软件开发过程当中，第二种模式其实并不常用。

因为迭代一生产出来的产品和迭代二生产出来的产品，在本质上有所不同。

甚至迭代一的设计在迭代二根本无法使用，同样，迭代二里做的工作在迭代三里可能也完全不适用。在这种情况下，我们进一步选用第三种开发模式。

 模式三 

 

在第三种模式下，第一个迭代直接就造出汽车，但是这个汽车可能是没有引擎，还需要有个人在后面推。

在第二个迭代里， 因为客户需要汽车能装东西，所以加了一个货箱。

第三个迭代，客户的需求是要乘坐舒适，所以底盘可以不变，只需再改造出一个比较舒适的驾驶舱。

在第四个迭代里，客户进一步需要更加美观的设计，所以在第四个迭代里又进一步做了流线型的设计。

模式三就是我们在日常软件开发过程当中常用的模式。

大家最好能以这种方式进行版本的发布。

这样，交付物能够更加及时地达到客户的预期，并且迭代之间的跨度并没有那么大，不会出现像模式二这样几乎每个迭代设计全部发生变化的情况。

 但这并不是说模式二没有任何可取之处。

很多项目在长期的开发过程中，的确在底层发生了大规模的重构。

比较典型的就是互联网产品 。

为了及时的把app推向市场，我们很可能只花一两个月做一个简易版本的app，这个app既不美观，也不能支持高流量、高并发。

但是我的产品在早期用户确实并不多，随着产品的发展，用户数不断增加，对用户体验、并发的要求也不断增高。

那么我们很可能在一个较长的时间，比如一年之后，对整个产品进行从头到尾的重构。这就类似于从一辆自行车变成一台摩托车的升级迭代 。

2.迭代开发的好处  

理解了迭代开发以及它为什么能够及早向客户交付价值，同样是敏捷思维非常重要的一点。

下面我们来看看迭代开发具体有哪些好处~

 好处一 ：及早交付

有这样一个计划：我们需要在40周的时间里去修十栋房子。

 # 瀑布模式 

 按照传统的瀑布模式，第1-10周全部都是做地基，第11-20周周都是在修墙，第21-30周做屋顶，如果计划不变，第31-40周就可以做完所有的房子。

但一旦计划有变，比如在第30周的时候整个项目停止了，可想而知这十栋房子的交付产生的价值是零。

这就是传统的计划驱动的瀑布式交付模式。

 # 迭代模式 

 如果是迭代的开发模式，迭代一的第一周就做第一栋房子的地基，第二周做第一栋房子的墙，第三周做第一栋房子的屋顶，第四周就可以完成第一栋房子。 

到了迭代二，很显然就是去做第二栋房子。迭代三就是第三栋。一直到迭代五，完成第五栋房子。

如果按照计划的话，整个迭代跑完，40周的时间就可以把十套房子完成。

这个时候一旦计划有变，比如在第32周的时候，外部环境发生了变化，整个项目停止掉.我们依旧可以交付五栋房子，可以完成整体交付价值的一半。

这就是用迭代开发进行早期交付的一个好处。

 好处二 ：降低风险 

 左侧是传统的瀑布开发模式，可以看到整个三角形都是风险区域。

按照这种瀑布开发模式，只有等到系统最终上线验收后，用户才能一次性获得所有价值。

而如果是用这种增量迭代的方式，我们可以看到红色所代表的风险区域面积会很小，因为每一次迭代都可以去交付一部分的价值，哪怕中途项目发生了一些变故，之前所做的工作依旧具有交付价值。

3.Scrum  

了解完迭代的概念后，我们会看到不管是Scrum框架还是极限编程，其实都是以迭代为基础的。

下面就来进一步看看什么是Scrum框架。

著名的敏捷专家、敏捷布道者Mike Cohn给出了这样一个定义：

Scrum是一个让我们关注于在最短时间里去交付高质量商业价值的敏捷框架。

简单来说，Scrum是一个框架，里面很多的工具和技术都是用于实践敏捷宣言的价值观及十二原则。

 一幅图看懂Scrum 

 三大角色 

在Scrum的团队里，有三类角色：

Product Owner

Scrum Master

Team

一个Scrum团队最好是全栈团队。如果是一个软件开发项目，那么团队里最好要有架构师、前端开发、后端开发、测试工程师。

一个团队的人数建议是5-9人，如果比5人更少，那很多工作往往就没办法推进了。

而如果人数多于9人，团队规模就会过大，进而造成许多浪费，所以推荐的是5-9人之间。 

 两大 Backlog 

 # Product Backlog 

这个指的是产品的待办列表。

我们可以把它看成是一个需求池，不管是产品经理还是BA，获取用户需求进行转化后，都可以放在Product Backlog里。

 # Sprint Backlog 

Sprint就是所谓的迭代，Sprint backlog指的就是一个迭代的代办事项。

 四会 

 # Sprint Planning Meeting 

这是整个迭代的计划会。

在计划会里，会从Product Backlog里拿出目前要做的工作事项，进行工作量的评估，并且将它放进Sprint Backlog里。

在一个sprint的1-4周时间期限之内，团队必须全力冲刺，完成Sprint Backlog里的各项工作。

 # Daily Scrum 

这是每日站会，或者叫Scrum Meeting。也就是团队成员每天要开的会。

 # Sprint Review 

这是指评审会，评审会会对整个迭代的交付物进行评审。

最好是客户也能参与评审会，让客户对交付物是否能够满足需求进行评审。

 # Sprint Retrospective 

这是指回顾会，是Scrum团队内部的会议。

会议会列举整个Sprint的过程当中做的好的点，以及做的不好的点。

这并不是由产品经理或者项目经理单独来复盘，而是由团队的所有成员来共同探讨，并且提出改进的解决方案。

文章来源：神州数码云基地