把敏捷放在地上，把敏捷放在心里
敏捷是工具
好吧，我坦白了，我欺骗了大家。最近我在游说大家辩证地看待“敏捷”，并期待大家和我对“敏捷”的理解到同一水平线上的时候，我曾大放厥词：“敏捷不是所谓的流程和工具，它是价值观”。但从一定程度上讲，价值观也只是我们用来解决工程问题，用来约束人思维而创造的工具之一，我也是Google了“价值观是工具吗？”这个关键字才学习到，哦，原来还有“工具价值观”这么一回事。从解决问题的角度来看，人发明出来的东西——敏捷，它不是个工具是什么？
但是，请不要暗自窃喜（就像学生时代指出老师错误那样），我曾提到的所有关于敏捷的理解都是值得各位深思的。而这里，这篇文章，我想和大家聊聊所有人心底的那个困惑：“请问我们到底怎么才能把那个该死的敏捷按在地上？”不瞒大家说，在此之前我也不知道怎么把我心里的和我那曾亲眼所见的我以为是敏捷的东西塞到你们的脑子里，并和大家一起愉快地写着代码，唱着歌就把项目给交付了。
甚至最近在和朋友吃饭聊天的时候，一位资深的敏捷交付专家都开始怀疑自己所理解的敏捷到底对还是不对，我们所习以为常的所谓的“正道”是不是入错了片场，我们应该怎么抉择和取舍？原来在野蛮的交付环境下我们也会感受到挫败与力不从心。
复盘过去这段时间在项目中推行敏捷的经历以及最近翻译的书《Robust Python》的启发之下，我想我可能找到了问题的部分答案（话不能说太满，毕竟我以为的我以为一定是我以为的吗？）。
工具视角
从该瀑布还是该敏捷，到是该Scrum还是该Kanban，再到该站会还是该坐会，到该不该Code Review，该不该写用户故事的AC，该不该持续集成，该不该TDD，该不该加班，该不该。。。我们有太多问题想知道答案了。除了告诉你咨询师的标准答案“看情况”之外，我是真的不知道以何作答。但是我想把“看情况”这个三个字换个说法并稍微解读一下：明智地权衡利弊（正是所谓工程问题的本质）；
先抽象一下，这些问题的“类”是：“某个工具该不该用，怎么用”。不过是个if else（决策）罢了，每一个决策背后都需要权衡利弊，我们听过太多人说敏捷软件开发的好处何其多，但成本是多少呢？敏捷转型是需要成本的，除了支付给咨询师的钱之外，更大的成本在于：
- 组织层面是否接受，说服组织接受它也是要成本的，有时还不菲。。。
- 一旦组织上决定敏捷转型，就会产生高昂的初始学习成本，团队不会一夜之间就理解并认同敏捷，也不会马上就学会成套的敏捷实践（这玩意儿有些单独拿出来做还没啥用），他们需要学习与实验，这太昂贵了，特别是在时间、金钱、精力都捉襟见肘的上下文中。
更糟的是，在一个中型或者大型团队中，早期需要投入的成本很可能远胜于获得的收益。这个问题本质上来说是一个先有鸡还是先有蛋的问题。在团队没有达到足够的敏捷成熟度之前，我们能看到的只有成本和越来越紧迫的交付压力。然而，人都是不见兔子不撒鹰的，看不到好处的情况下让大家接受并实践敏捷是很困难的。
我们能做什么
从我们过去实践敏捷的经验来看，可以尝试将成本与收益随时间的变化这样建模：
成本收益曲线.png
成本一开始会很高，但随着团队敏捷成熟度的提升会逐渐降低。而收益一开始会很低，但随着团队的成熟会越来越高。在这两条曲线相遇之前，我们可能感受不到敏捷实践的优势。所以为了价值最大化，我们需要尽可能早地达到这个交叉点。
痛点驱动变革
软件系统问题的与传统工程问题的最大区别是我们应对的是理想化的世界，我们不需要考虑物理世界类似公差这样的问题，我们要处理的90%的问题都来自于人。所以我们说软件设计与开发要“以人为本”。既然是人的问题，那无非是兵来将挡，水来土掩。当我们感觉痛的时候，就是我们要动的时候，不要痛到麻木，然后躺平。
产生价值的最好的方法就是减少正在经历的痛苦。我们可以回头看看自己当前的工作方式中，哪些地方浪费了时间和金钱？哪些东西让客户失望？以及哪些东西让团队士气低落？好好做回顾，做根因分析。如果你明确地知道痛点所在，请尝试那些大家都说好的敏捷实践，并试着坚持一段时间；否则，我建议从正确的Retrospective开始做起：
- 选择合适的手段
- 保证安全的环境
- 暴露有用的问题
- 产出可测试的行动计划
- 投入适当的成本以解决必要问题
- 设定Action的Owner
找战略目标
是不是没有“敏捷”就不能做价值交付？显然不是，这也正是敏捷的魅力所在，敏捷的价值观里总是用发展的眼光看待人和事。除了“敏捷”和“非敏捷”，我们永远有一个说法叫“在路上”，当然我们可能永远都在路上。
人可以走向天堂，不可以走到天堂。走向意味着彼岸的成立，走到岂非彼岸的消失?
——史铁生
关键节点与事件
在软件咨询服务领域，我们通常将软件开发称为“价值交付”，一个非常商业的词汇。而商业中通常有一些关键的时间节点与事件是需要我们重点关注的，比如：签约、验收、交货、交钱。对应到软件交付的上下文，这些事件就显得比较关键：需求挖掘与业务分析、确认交付范围、软件验收、集成与部署。所以，我们应该针对具体的事件正确地采用其对应的改进方法：设计思维之于业务分析、SPM（Sprint Planning Meeting）之于确认交付范围、Sprint Review之于软件验收、CI之于集成与部署。
混乱与冲突之源
我们看到有些痛苦一直在发生，从来没有停止过：客户反悔了、开发和产品经理（BA）吵架了、前后端联调出问题了。放弃美好的幻想吧，上述这些一定会发生，毋庸置疑。所以你是打算束手就擒还是坐以待毙呢？哈哈，勇敢一点，接受它们存在的必然性，试着反其道而行之。比如，更频繁地让客户反悔（尽可能短的迭代，与客户建立有节奏的，高频的反馈环），设定专门用来给开发和BA“吵”清楚需求的流程——SPM、用户故事的Kick Off，让前端和后端开发可以一直吵（重新定义卡Done的标准，让他们坐在一起一起工作），当然能推行全栈文化就更好了。
世界上只有一种真正的英雄主义，那就是在认清生活真相之后依然热爱它。
——罗曼罗兰
一劳永逸地解决复杂问题
我们通常都需要花比较多的时间来解决复杂问题。比如：新人的知识传递。而可以改进的点在于当我们花时间完成它之后应该尽可能让下一次再做的时候花更少的成本。所以，对项目制的团队而言，请像维护代码那样维护好新人 On Boarding 的 checklist ，不论是关于技术还是业务的。
