Control your tempo then build slowly.
—— Creed(2015)
在拳击的宣传视频中，我们经常能看见拳击手击打速度球的片段，看起来双手交替往复，好像只要你足够快就能玩得转。直到看见了《奎迪》的这个片段才发现，原来速度球的击打跟项目的敏捷开发管理是如此相似，单纯追求绝对的速度是没有意义的，基础在于对球路的控制和预测，最终的快不过是这种控制之下的表现罢了。
大概5-6年前吧，基于Scrum的一整套敏捷项目管理方法开始从互联网公司推广起来，站会、需求池、任务拆解、Jira、Jenkins等一系列概念、工具也被同步引入。现在回过头来看看，这几年的职业路径恰好拟合了Scrum在软件行业中的渗透路线：互联网公司 -> 开始互联网化的传统公司 -> 想要互联网化的传统公司 -> 不了解互联网是什么的传统公司……
所以每新到一个地方，都会经历一遍公司花高价请来敏捷教练去尝试转型的过程。公司越传统、无法避免的流程就会越繁重，对干活的人来说，自然是希望敏捷能把各种繁琐的形式化流程砍掉；对领导而言，则通常是被灌输了敏捷是万能灵药的迷魂汤，好像有了敏捷就能在不增加任何投入的情况下更快的、完成更多的项目。
可敏捷的本质是控制，是让领导、让干活的人更清楚自己将要和正在做的事情，真正敏捷的是过程中问题的发现，基于这点再来看看Scrum中的关键要素无不是为加强控制而存在的：
- Product Backlog（需求池）：一个具有优先级排序的需求池，既能让领导看见产品的远期规划、又能让开发聚焦于近期目标；
- Daily Scrum Meeting（每日站会）：让团队管理者能及时了解项目的任务状态，同时也让开发者及时抛出遇到的问题；
- Sprint（迭代）：快速完成最小化的产品交付，尽早的从市场获得问题反馈；
- JIra：我一直都觉得，Jira就是附送了工作流引擎的图表统计工具，在项目越来越大、人员越来越多的情况下，就无法再依靠管理者的大脑或是纸笔来进行任务的状态的跟踪管理了；
- Jenkins：固化的流程，由机器来完成，才能解放出人力去从事更多创造性的工作，并且最重要的是，机器没有人类的情感，不会疲惫、也不会犯错。
所以说一家公司最终能否敏捷转型成功：
- 首先看的是决策层对于敏捷的理解，是否能意识到敏捷其实是自己对公司人员控制的工具，而不是可以当甩手掌柜的万能钥匙，如果意识不到这一点，最后敏捷的各种控制要素就会流于形式化，因为没人知道为什么要这么做，而只是知道规定要这么做；
- 其次看基层人员对于新事物的接受度，在决策层无法正确认识敏捷本质的前提下，如果基层人员有足够高的新事物接受度，也是有一定概率能够转型成功的，但事实上在越是传统的公司里，大家在各自领域铸起的壁垒就越厚，对于新事物就越抵制。