敏捷是知与行的功夫

敏捷不是“一”种方法

“敏捷是一种用于项目管理和软件开发的迭代方法，可帮助团队更快地向客户交付价值并减少风险。它不是将一切都押在“大爆炸”发布上，而是以小的增量交付成果。不断评估需求、计划和结果，因此能够快速地响应变化。”

以上是一段常见的关乎敏捷的定义。

而当我们动态地看待过去几十年的敏捷发展史，光是围绕敏捷二字产生的框架、实践、理论等，便是五花八门。

早期的时候，有诸如 Scrum、XP、Crystal method、DSDM、FDD 等框架，又有融合了 TPS 的 Kanban，而后敏捷理念日渐传开，过度商业化带来各种乱象的同时也伴随着拨乱反正的进行，这期间又出现过一些新方法，如Modern Agile， Heart Of Agile等。

另一边，DevOps运动，精益方法，逆康威行动等也都在如火如荼地进行，倘若我们认真读过敏捷宣言背后的十二条原则，也不难发现敏捷与它们之间的默契。

如此看来，将敏捷说成是单一的方法本身不免过于狭隘。

既然否定了一种定义，势必要肯定一种定义。社区中Being Agile not Doing Agile的说法流传已久，其巧妙之处便在于指出了敏捷本身是一种思维方式。

处于日新月异的技术环境下、变化多端的市场中，软件开发活动若想能迅速响应外界变化来高效地完成商业目标，寻求与VUCA/BANI/RUPT/TUNA（无论你喜欢什么词）环境的对抗之道是必然的。

敏捷应运而生。

然而因其所对抗的环境是极度复杂的、无规律的，固然敏捷也无法是一种或两种方法，它首先是价值观，而后伴随着方法、框架、实践等，总体上呈现出随时代发展、行业进步、人们对软件开发活动认知的深化，本身不断演进，并与类似价值观下的其他理论或方法互相包容的特征。

敏捷不解决软件的复杂性

《没有银弹：软体工程的本质性与附属性工作》中曾称：

“没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍。”

抛开具体的数字而言，软件开发是一项复杂度高且充满不确定性的活动的事实依然未变。

从对立统一的角度来看，软件优秀的特质通常与其令人苦恼的特质是一体两面的。

软件的变更成本可以很高或很低，构建一款同样的软件有数不胜数的方式，即便在功能都完全一致的情形下，也存在易于拓展和复杂僵化两种截然不同的可能性。这都因为软件开发活动本身是一项熵高的活动，倘若构建软件的方式是单一的、按部就班的，便也不存在这样的区分。

在XP2002的大会上，一位经济学家Enrico Zaninotto提到，在软件开发和制造过程中，不可逆性是复杂性主要的驱动因素之一，敏捷方法通过降低不可逆性来包容复杂性，而不是解决其他的复杂性驱动因素。

这段描述确切地指出了敏捷的根本点，不是解决软件开发活动本身的复杂（目前看来也不可能），而是极尽所能去应对。这势必导致这种应对方法本身一定是灵活变通的，它趋向于通过建立对软件开发活动特性的把控，从而衍生出具体情境下具体的解决办法，而非借以单一固化的流程或方法来解决问题。

如果一个希望从敏捷中获得好处的企业，仅通过购买咨询、培训等服务，而不自发地在实践中增强组织对于自身业务、软件开发本身的认知（固然框架和实践是有用的，即使在对其背后价值逻辑全然不知的情形下，某些实践也能带来收益，例如持续集成），却也只能受用敏捷能够带来好处的九牛一毛。

正如Dave Thomas在GOTO Reference中对”是否能够及如何购买敏捷力？”这一问题的回答：

“不，你不能，但你能够购买对此有帮助的润滑剂。它（指敏捷力）从实践和经验中得来，你无法单单通过咨询、读书、上课等等来获得，它从不断的试错中而来。你需要发展隐式的知识（一些你难以表述甚至都不知道自己知道的知识）。
所以你无法购买敏捷力除非有人能发明这样一种机器：戴个头盔在你头上，按下按钮，然后你就能说西班牙语了。不过你能够购买工具、经验，但你仍需要大量的工作，或许花费数年才能完成。”

敏捷是知与行的功夫

王阳明心学中有知行合一的认识论，即知行原是两个字，说一个功夫，不可分作两事。

“知之真切笃实处便是行，行之明觉精察处便是知”

相信这样一个场景大抵不令人觉得陌生，

在进行用户故事工作量估算时，其中一人称：“我认为这个故事的工作量是三个点，因为它涉及到很多结构性的调整。”，另一人说：“我赞同你的说法，但在我看来这些调整在IDE工具的帮助下并不是什么难事，并且我们应该尽可能简单地先做出一个版本，所以我认为只有两个点。”

在这样讨论当中，实则揉杂了两方面的事情。一方面，是对于故事认知的拉齐（价值，技术思路，风险，难易程度等），另一方面，是基于共通的认知，成本又作何算（所谓的点数）。

前者叫做澄清，有助于识别风险，令团队对故事达成一致的认知，使后续落地工作中得以更好的进行。同时这样的过程有利于成员间知识经验的交换。

其关键点在于恰到好处的颗粒度，我们需要讨论到这样一种具体的程度：对价值、风险、工作量等等的影响是什么，但无需再更进一步。

就上述而言，另一人的说法中，“并且我们应该尽可能简单地先做出一个版本” 这样的陈述便是不具体的，听众无法理解其中“简单”的程度，而“简单”的程度恰恰对应着不同的价值与成本。

倘若是这样的描述：“并且我们应该尽可能简单地先做出一个版本，它只应该在现有应用的XXX处做XXX的修改，而不应涉及到XXX以及XXX…”，想必讨论的立足点会更为坚实。

而后者称为估算，误解颇多的一项技术，Martin Folwer 在他的一篇bliki，估算的目的中指出：

“对于我来说，当你面临重大的决策时，估算就是有价值的”

这反倒是众多施行估算实践的人所忽视的一点，他们往往这般回答：我要知道每个迭代我们能够完成多少工作量！倘若追问然后呢？

便有人说，这样我就能在开发人员完成度不达标的时候指着他们的鼻子说，“看，你们自己承诺的，结果做不完，你们说怎么办！”

也有人说，我想根据迭代完成工作量的波动来识别哪个迭代中可能出现了问题（例如交付的平滑程度，技术债务堆积产生的负面影响），这样的想法有其道理，只不过识别这些问题常有更妥善的方式（比如以分析故事在各阶段的停留时长，技术债的定期评估等）。

还有人说，我希望借此把控项目能在约定时间内按约定范围交付。这乍一看确是稳重的想法，然而把按时按范围当作目标，本身和敏捷理念相去甚远。敏捷始终是奔向价值，时间和预算只是约束，我们无非是要探寻在有限的时间金钱条件下，做什么是最有价值的，然后又快又好地完成它。倘若我们半年前设定了一个目标，便当这个目标是不变的圣旨，这样的思维也是死板教条的。

综上而言，敏捷的功夫是知行的功夫，实践要做，理论也要懂，丢了一个便是全丢。唯有在实践中丰富我们的认知，又用认知来指导实践，反复循环，培养既抽象也具体的知识，才能做到真正的敏捷。

敏捷需要管理者响应一线需求

也许敏捷先行者们吹嘘从敏捷中捞得的好处时，词藻过于华丽，一些大公司听在耳中，看着自己每况愈下的财务报表时，也把目光投向了敏捷。

一时间，规模化敏捷炙手可热。我们看到SAFE、有LESS、有Scrum@Scale等框架如雨后春笋般冒了出来，这些框架的出现在规模化敏捷的试验田里率先种下了发展的新苗，然而另一方面，它们依然立足于理论的高点，只是从象牙塔内望向外部混沌真实的世界。

构建全功能的团队自不必多说，长久以来团队级的敏捷经验充分地印证了这一点。DevOps运动的起源故事也证明了，只制造中间产物的部门或团队甚至在应对一点微小的变化时也是惊人的笨重。

关于团队级的敏捷，许多规模化敏捷框架倒是聪明地借鉴了现有的Scrum、Kanban、XP等方法，而在如何组织多个敏捷团队这一方面，却是出奇一致的天马行空。无论是SAFE的Agile Release Train， LESS的Head Of Product Group，Scrum@Scale的SoS，仿佛从每个敏捷团队中抽出一两个关键角色，和远离用户的管理层组成个精英小队发号施令，便能引领各个团队披荆斩棘一往无前。

事实上，倘若团队自身无法处理好他们的业务，需要来自“精英小队”的指导，这便和从前也并无区别——整个组织的业务依赖于一小波“聪明人”的智慧和大部分“不会动脑”的人形机器。

而如果团队能够自己处理的好，他们也不需要“聪明人”的自作聪明，相比之下更重要的是足够的权利和资源。

SuperCell的成功令人眼红，在他们的经验总结中提到信任而不是控制，CEO Ilkka Paananen说“我是开发团队的服务者。”，这很好地揭示了大型组织要在实施敏捷时的常见误区：管理层不去释放掌握的权利和资源，相比支持前台的业务团队，依然还是控制的思维。在一个大型组织中，倘若我们说要Be Agile的话，不光是要让一线员工学会响应来自市场的需求，二线的管理者和组织的运营者们也要学会响应来自一线的需求，正如TPS中的拉动生产方式一般。若是到了管理层这就脱节了，把一线夹在市场的变化和二线的控制之间，是做不出敏捷的。