前言

为什麽选在这个时候切入「敏捷」呢？在这之前我们谈论了「沟通」、「当责」与「透明」，这些都是展现敏捷的重要关键。

敏捷

谈到敏捷，着名的「敏捷软件开发宣言」铁定少不了，也因为它的篇幅很短，容我在此再引用一次。

个人与互动 重於 流程与工具
可用的软件 重於 详尽的文件
与客户合作 重於 合约协商 
 回应变化 重於 遵循计划

在 A Behind The Scenes Look At The Writing Of The Agile Manifesto 一文当中，我们可以看整个宣言是如何诞生的，并且从 Andy Hunt (即宣言作者之一，当时署名为 Andrew Hunt) 的手稿上看出一件有趣的事，无论其他三个的顺序如何变动，Individuals and interactions over processes and tools 始终位居第一，显示「个人与互动」是整个敏捷当中的重中之重。

而在宣言背後还有 12 条「敏捷原则」，也非常值得一读，这边就请读者前往查看了。读完之後，自然可以从中摘录几个关键字，例如：交付价值、面对改变、频繁交付、紧密合作、保持沟通、自组织、自省。

那又是什麽可以支持这些原则呢？前几天提过的「沟通」、「当责」与「透明」就是很好的实践指引。

为什麽要敏捷

我们团队执行 Scrum，这边就以它来说明。Scrum 作为一种敏捷框架 (Framework)，拥有易学难精的特性，难精我们先不要看，不然文章不好接 (喂！)。

在我们要跑 Scrum 前，我是这样向团队说明的：「Scrum 提示我们事情本该如何做」，我们只是借着 Scrum 定义的角色与活动，来帮助我们发挥本能，让我们充分知道我们正在做什麽，让我们可以从容应对变化、可以流畅的交付价值，一旦展现这样的精神，那麽敏捷与 Scrum 这些名词都不再重要了。

也就是这样，没有为什麽需要敏捷，而是这样做是自然的、是符合常理的，我们本来就拥有应对变化的能力，反到是在工作上僵化了。当我们驾车「冲刺」时，不会紧踩着油门不放，而是注意车况并随时调整，不是吗？

如果多多观察，会发现生活上充满各种变化，又急又快，甚至还在加速着。 “VUCA” 一词就传达了这个概念，这也早就体现在工作中，在你感叹「陨石又砸下来」的时候。关於这个主题我安排在更後面的文章，现在我们先专注在敏捷身上。

同时，我认为敏捷也没有什麽好失败的，差别只是面对变化时有多麽优雅罢了。有了这个认知，再回头阅读敏捷宣言与原则，你可能会更有共鸣。假若你的团队运作一点问题也没有，那要不要敏捷也不是那麽重要了，又或者说本身已经敏捷了，所以学习、讨论敏捷时，不要过度纠结在「敏捷」这个词，它不是旗号，而是个实际。

至於「难精」呢？做了才知道，随着各方面的问题被暴露出来，团队必须拿出行动力来解决。

敏捷也要敏捷

有一个值得反思的现象，在导入敏捷时通常会有反弹，这是人之常情，而运作一段时间更可能会有人产生质疑，质疑我们是不是导入失败了呢？

正如文章前面提到，我认为敏捷没有失不失败的问题，同时也要提醒：敏捷导入的过程本身也是一种「敏捷」。

若有人感到「是不是失败了」，本身就是个机会，一个已经被看到的问题 (现象)，接下来就是去应对它了，千万不要看到一个失败，就断了後面的所有机会。反过来说，如果一切都很顺利，如同工程师不知道自己的程序为什麽可以执行，那这样的「敏捷」不是令人发毛吗？

会有这种现象，也许是过度执着在「敏捷」两字上面，而忽略了它的本质。

我要开始敏捷了

「交付价值、面对改变、频繁沟通、追求卓越、反思修正」，容我再次压缩敏捷原则，在看到这些原则，不知道各位有没有问过自己：「我敏捷吗？」。

让我们从生活上来思考：

1. 塞车了，我是想改变路线，还是继续等待？
2. 我想改变路线，那我真的能够改变吗？
3. 请导航机算条替代路线，啊！导航机没有即时路况
4. 问问某家的地图，它有即时路况
5. 太好了，有条替代路线可以走，前方路口就是突破的机会，等下右转。

请问，我们可以从 1 走到 5 吗？还是在第 1 步就放弃了呢？

6. 这条路真是畅通，果然之前改变路线是对的。
7. 孩子：「我要上厕所」。

那现在呢？是不是先抱怨为什麽忽然要上厕所，这样会打乱原有的计画。不行不行，这样是不行的，听说「敏捷」可以应对变化，那我也要学。

希望这个小剧场能够让我们反思「导入敏捷」这回事，思考这位开车的父/母，究竟要学什麽呢？