ThoughtWorks的敏捷开发

ThoughtWorks的敏捷开发方法一直是一种神秘存在。在敏捷开发还没有主流化的年代，为了让外界理解ThoughtWorks全球团队怎么做敏捷，我们商定了一个“60% Scrum + 40% XP”的经典答案。当然其实ThoughtWorks的敏捷开发既不是Scrum，也不是XP。

造成这个状态的原因，一方面是行业特点 —— 软件开发还是一个充满不确定性的手工业，方法套路当然不可避免因人而异；另一方面作为一个提倡端到端软件交付的组织，敏捷开发本身并不能解决我们所有的问题。基于这两点，大家都不是特别愿意去总结ThoughtWorks的敏捷方法，换言之“标准化”就不在我们的基因里。

标准化的初衷

那么为什么这个时间点来谈这件事情呢？从我个人角度来说对内对外都到了必须总结的时间点。在上一篇文章《忘记“规模化敏捷”》中，我批判了市场上的所谓规模化敏捷框架，如空中楼阁，概念打包。但这样的现象确实也表明敏捷开发已经进入大规模采用阶段，一定的标准化是必须的。

ThoughtWorks快20年的敏捷开发实战经验不总结给更广大的社区，于我自己感觉是一种不负责任。对内ThoughtWorks中国已经从我加入时，北京东西宫每天流窜两趟招呼到所有人，变成了全国六地1,200多人的数字化服务公司。每年还是很多人为着敏捷慕名而来加入ThoughtWorks，而我能给新员工分享一点敏捷开发实践的机会可能一年一次都难了。

留在ThoughtWorks的一个重要原因就是差异永远大于共识，这样的环境里想总结点啥，没实战经验保底肯定是会被鄙视的。作为一个开发加入，在近十年的ThoughtWorks生涯里，我做过敏捷开发里除了测试以外的所有角色，如果把咨询的部分经验算成敏捷教练，和最近在努力的UX方向，应该是给了我足够全面的视角来审视ThoughtWorks的敏捷开发。在中国区持续最长时间的离岸敏捷交付团队近4年的经历，和敏捷咨询8年的经历也应该让我有一定经验支撑来谈这个话题。

标准化的范围

即使有上面的经验，也只能聚焦在“开发”，而不是“ThoughtWorks敏捷”。针对市场探索和产品创新的方法仍然存在根本性认知上的不同，数字化时代的不确定性又让此刻去更大范围标准化的想法不切实际。但我认为敏捷开发 —— 即从开发团队启动交付到持续迭代运行 —— 已经为我们应对市场不确定性，构建高响应力组织，提供了基石，让我们能够在数字化时代将整个软件开发逐渐改进为真正的价值和成效驱动，而不仅仅是快速交付了一堆不知道有用没用的特性。

在下面的总结过程中有两个“技术处理”希望大家理解。

第一，软件开发手工业的属性造成了不同的团队成熟度显然是不同的，总结的ThoughtWorks敏捷开发实践并非所有团队都能够做到，但我强调的一点是所有团队都共识这些实践是有价值的，可能出于某种外部约束做不了，比如部门墙造成业务人员无法参与。

第二，尽量不引入ThoughtWorks自己的“黑话”，跟Scrum、Kanban和XP这些经典框架相似的实践，保持命名一致，毕竟标准化的作用之一是对外推广。

换上咨询顾问的帽子，ThoughtWorks敏捷开发方法应该是现在市面上实践过程中最接近敏捷宣言价值主张的实战了。当然距离理想的价值和成效驱动的精益模式仍然有相当的距离，面临的挑战和困难可能不是敏捷开发能够解决的，但这些问题现在却反过来在压迫正确的敏捷开发方法，造成不少团队越来越多的困惑。当一个有追求的开发团队需要持续去解释TDD和Pair不会降低效率时，技术卓越的追求就在逐步被消磨了。

ThoughtWorks敏捷开发核心原则

铺垫很长，希望尽可能在讨论范围上保持客观，现在让我们一起来看看ThoughtWorks敏捷开发模式。

为了帮助大家理解，我尝试从软件开发实践和管理体系两个维度去解释。先列举一下核心实践，然后从软件开发的几条管理主线帮助大家串联一下这台看似松散，实则精密的机器。这里要再次提醒大家我们讨论的范围仅仅是开发段，所列实践也不会特别关注团队文化建设。

在展开具体实践前，首先要明确ThoughtWorks敏捷开发的核心原则：价值驱动、技术卓越。

这两个四字短语在ThoughtWorks这个开发系统里有着不可撼动的地位。毕业刚加入的热血青年质问项目经理一个Story的价值何在？Angluar和React谁更全面？这样的讨论在内部是被鼓励的。

这两个核心原则甚至上升到了价值观的层面，于是我们认为