前言

在前两期，我们分别澄清了【敏捷的常见误解】和解读了【敏捷思维与原则】。本期我们一起跳出局部思维，俯瞰全局，全面深入地认识和学习敏捷。

敏捷技术全景图

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

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

敏捷思维，也是如此。

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

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

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

“术”

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

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

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

Scrum

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

看板

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

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

XP

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

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

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

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

SAFe、LeSS

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

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

DevOps

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

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

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

实践角度看敏捷“技巧”

用户体验地图

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

每日站会

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

结对编程

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

（图片来源于网络）

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

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

TDD

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

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

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

持续集成

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

“器”

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

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

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

版本控制工具（GitLab、GitHub）

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

白板、便签

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

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

敏捷团队的特点

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

特点一：自组织自管理

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

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

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

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

特点二：完全透明

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

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

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

特点三：自适应

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

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

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

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

如果敏捷团队的成熟度还不够高的话，我们也可以使用各种各样的办法进行提升！

在下期内容中，我们会讲到一些具体的实践，比如项目迭代和Scrum框架，从更直观的角度理解这件事情，敬请期待吧！