敏捷宣言最误人

算起来自己从事IT行业也有二十多年了，前前后后在各种规模的团队都呆过了。也做过很多种的角色，刚毕业的时候做编辑，后来做程序员，运维，测试，再到后来做项目经理。后来自己创业，产品经理、运营、市场和销售也都干过。如果让我总结一下自己过去这二十多年的收获的话，有一个词是特别想和大家分享的，那就是平衡。

先来举例子。比如我以开源的方式来做禅道项目管理软件，是一种平衡：在商业和社区公益之间寻求平衡点。业内有很多非常纯粹的开源软件开发者，从来不考虑商业方面的东西，非常值得钦佩。但一直用爱发电，很难坚持下去。另外一端，有很多企业也想用开源的方式来经营自己的产品，但开源版本只是用来吆喝的噱头，功能严重不足，也没有支持，这也不是我们想走得路。我在2007年的时候写了一份禅道项目管理软件的商业计划书，当时就明确地定下了用商业的方式来做开源软件的策略。这十几年下来也还算是走得不错，算是国内为数不多的能够跑通商业模式的开源项目。

我是Linux控，从开始学习计算机就接触到了Linux和各种各样的开源软件。在使用这些开源软件完成我日常工作的同时，我还从这些软件背后学习到各种管理的思想。我和团队的同事一直分享一个观点，就是把计算机科学当作管理学来学习。计算机里面的每一个解决方案背后其实都是取舍，取舍的背后我的理解就是平衡。

回到敏捷宣言，敏捷宣言里面明确地阐明了自己对左右两项价值的认可程度是不一样的。

个体和互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值。

站在敏捷宣言提出的时代背景来看，我认为是没有问题的，矫枉必须过正，不过正不能矫枉。在当时的时代背景下，敏捷开发作为一种革命式的研发方法提出，是需要旗帜鲜明的提出自己的观点。但时至今日，敏捷宣言里面的这些价值主张，往往会被用户曲解、利用。大家更容易从一个极端走向另外一个极端，完全丢掉右侧的东西，偏向左侧。这也是为什么大多数的团队在实施敏捷开发后效果并不好的原因。右侧是一个团队协作的基础，左侧是团队敏捷能力的表现，左右两侧需要平衡，才能达到更好的敏捷状态。

先来看个体和互动高于流程和工具。

很多团队在实施敏捷开发之前，会有比较严格的流程和工具，会有各种各样的检查评审。流程会比较多，会让人觉得麻烦，对个人的天性也会有一定的压制，但可以保证团队按照一定的规则运转起来。那实施敏捷开发之后呢，大家就觉得终于解放了，流程啥得都可以不用了。像极了刚上大学的学生们，终于可以摆脱作业、考试，可以放飞自我了。然后就悲剧了，很多学生大学四年啥也没学到，身体反而搞垮了。

敏捷开发其实更考验团队的纪律和规范。比如Scrum流程是否有严格地执行。我了解很多团队实施Scrum就只剩下一个站会，其他的都形同虚设。再比如极限编程，究竟有几个团队能够严格执行呢？代码规范、自动化测试、代码评审这些基础的实践是否都有在坚持做呢？完全靠人的主观能动性和自觉，我觉得是行不通的，需要流程和工具来进行约束。

再来看工作的软件高于详尽的文档。

这句话的关键是我们如何理解文档的定义。敏捷开发模式下我们不需要写那些繁杂冗长的八股文式的文档，但这并不意味着文档消失了。我们写文档的目的是为了对齐，对齐需求，对齐设计，对齐规划，对齐测试。在敏捷开发模式下，文档转换成了一条条的用户故事、转换成了一个个的迭代计划、转换成了看板上的一个个卡片、转换成了一个个的接口、转换成了一个个的任务、转换成了一个个的类、一个个的方法、一个个的参数、一个个的单元测试用例。那么我们有认真写这些东西吗？

就拿用户故事来讲，我们是否有将其梳理得清清楚楚，标题、描述和验收标准都非常清楚，逻辑合理，容易理解？大多数的团队能够做到把用户故事拆分出来就已经很不容易了。以前的时候需要写什么样的文档都有明确的规定，有各种的评审流程来确保文档基本的质量。但实施敏捷开发之后，这些流程规范减少了，但大家的沟通表达能力并不会随着这些规范消失而提高。在之前流程约束下，还能保证基本的沟通，到了敏捷开发模式下之后，反而可能会更差了。表现就是频繁的需求变动以及随之而来的代码质量问题，可工作的软件从何谈起呢？

我们接着来看客户合作高于合同谈判。

禅道团队也经常给客户做定制开发。从我们几百个客户的实施经验来看，客户合作的基础是合同。合同是啥，是双方的基本共识。如果基本共识都没有，再好的客户服务意识也无法保障高效的合作。我们推掉过很多定制，是因为我们的产品功能和客户要的功能不匹配，从0到1帮客户开发也不是我们的发展方向。这种不是说靠客户合作就能完成交付的，因为缺少基本的共识。

我从来不要求销售团队一定要怎么样，禅道团队的价值观里面也没有客户第一这类的说法。我们坚信好的服务是靠专业的团队来实现的，所以我们会提求真、为善、互信、利他，会站在双方平等、互惠互利的基础上来寻求双方的共赢。在过往合作过的客户案例中，也会有分歧、争执，但我们基本上都可以按期甚至提前完成交付，这背后对我们产品功能的坚持以及我们对品质的要求是分不开的。

最后来看响应变化高于遵循计划。

乌卡时代是需要我们快速地影响变化，但这绝对不是我们忽略战略规划的借口。很多团队实施敏捷开发之后是快速响应变化了。是如何响应得呢？靠996的加班，靠对一线员工的极限压榨。很多团队的战略变来变去，产品改来改去，需求频繁变更。这种绝对不是响应变化的正确姿势，深层次的原因是团队在战略规划上的短视。

拿我之前在雅虎中国的工作为例。我们部门负责竞价排名系统，每次产品经理丢过来几个一句话需求，我们吭哧吭哧干半天，好不容易做完了。下个迭代的需求又推翻重来，从来感受不到产品持续改进提升的乐趣，最关键的是我当时做测试，总是上线的前一天我才能拿到可以测试的代码，上线时间是不会变更的，我只能加班，所以我很不快乐。

所以响应变化应该这样理解：战略上要做深刻洞察，并保持定力，产品应当保持持续改善，提高团队的工程能力来加快交付。但现实情况是战略上缺少长期主义，产品也缺乏独立创新，工程能力也不重视，最后唯一能做的就是堆人堆时间哦。

我从去年开始练习瑜伽。没有练瑜伽之前我觉得教练好厉害，随便就可以来个倒立，来个后弯，来个一字马。但当自己开始练习之后，才发现瑜伽也讲究的是平衡：力量、柔韧性、呼吸等，以及对身体各部位的感知和控制。当这些都达到一定的程度后，高阶体式就自然而然地可以做到。但如果一上来就片面追求某一方面的训练，反而容易受伤，适得其反。敏捷开发也是如此，与大家共勉。