我在ThoughtWorks学软开（一）敏捷之于开发如同蜜糖，甜到发腻齁到忧伤

一、敏捷已死，有事烧纸

21世纪刚过一年，17位在软件开发各领域有所建树的大师汇聚在在美国犹他州，发表了似乎每个聚会都要发表的宣言（《敏捷软件开发宣言》），并成立了Agile 联盟，时间过去了十几年，现如今当初的17个人里有很多人都认为敏捷已死，let it go。敏捷似乎在21世纪初软件开发还在野蛮发展，不存在标准化的年代里满足了开发者对于软件开发的所有幻想，是当时人心中幻想的轻量级、高效开发方法，但是随着软件开发的逐渐成熟和软件从业者水平的逐渐提升，新任的开发者发现不需要那些太过于错综复杂的“神圣的方法论、奇怪的术语、神圣的工具和一堆诡异的行为”就能够在互相协作中达到高质量的交付，而敏捷的践行者本身也在逐渐遭遇自身的问题，比如敏捷开发模式的标准化、规模化敏捷和商业模式变化等等，因此敏捷也在逐渐从一套宣称“包治百病”的理论转变成为走到生命尽头的方法论。

关于敏捷是如何从一套先进的轻量级开发思想，转变成各大咨询公司蜂拥而至争相吹捧的大而全的框架的，笔者未曾亲历敏捷由盛及衰的辉煌十数年，敏捷领军者ThoughtWorks目前正在所倡导的标准化和规模化，笔者也算亲历其中，本文中所说的敏捷，只是我定义的“适用于小规模团队（特别是软件咨询和交付团队）的能够指导团队提高交付质量的价值观及一系列最佳实践”，在后续的分析中就能看到，这种情况下的敏捷其实是最能发挥其强大优势和力量的场景，经历了一圈荣辱是非，敏捷回归原本使用场景，恰好我还有机会能够经历感悟。

二、敏捷到底是什么

老生常谈的话题，敏捷到底是什么，这一次没有层次高超直达商业价值高度的高级咨询师，仅仅是从一名完成交付任务的咨询侧开发，与一个也在学习和应用敏捷，但是却是在自建功能团队实践敏捷的团队工作经历对比，给出敏捷的一个基本概念的解释。

敏捷其实从根本上来说，就是一套有利于迅速澄清和交付用户的需求的方法论，从根本上来说敏捷注重四个价值，较之于过程和工具，更注重人及其相互作用的价值。较之于无所不及的各类文档，更注重可运行的软件的价值。较之于合同谈判，更注重与客户合作的价值。较之于按计划行事，更注重响应需求变化的价值。整体上来看，这就是一套十分适合于软件外包和交付的思维，这也是敏捷能够在ThoughtWorks得到实践的重要原因。

敏捷主张最重要的三点是简单设计、拥抱变化和快速反馈，强调在项目开始时于客户沟通和澄清（Align或者拉通，随意叫）需求（一般以Inception为方式），并以快速迭代的方式持续小规模交付客户关注的价值，从几周到几个月，时间尺度越短越好，在开发中提倡使用简单化、可持续的技术开发，并通过重构方法逐渐迭代直至完成，在工作中可以随时接收和相应变化。听起来对于客户来说十分友好了，一个在项目开始时能够充分理解客户需求、项目中间能够响应客户变化、开发过程中可以每天于客户面对面开短会（站会）回报项目进度的开发团队，几乎可以说是完美了。

而对于一名开发者的角色而言，这些是敏捷独有的开发流程：

2.1 Inception

为了能够在项目启动前充分收集客户的痛点和需求，一般项目以Inception开头，一般需要BA伙同资深开发与客户窝在小房间里开长长的会从各个角度对客户进行采访和提问，涵盖产品所涉及的各个角色，充分收集需求。在这个过程中对于开发的要求是能够根据客户的需求快速进行需求的甄别和可行性的估计，有些团队也会要求Inception结束时能够给客户勾勒出一个产品蓝图，并给出产品大概的开发时间，交由客户决策是否立项。

2.2 Iteration 0

Iteration 0是整个开发过程的起点，这个迭代主要做的工作就是搭建开发所需要的CI和CD环境，配置打包工具和代码审查工具，配置各种账号的权限和招募开发人员进入组中，算是整个迭代的起点。ThoughtWorks内部采用松散而扁平的社区模式组织人员，虽然开发都由人事（People）评判业绩表现，但是理论上开发可以自由选择在各个项目甚至各个角色之间转换，因此Iteration 0一般是普通开发进组的正确时间。

2.3 Epic Story/User Story

由专属客户业务分析师（BA）或者替代其的技术领导（TL）与客户沟通之后收集到的客户的需求被分为史诗故事和用户故事，史诗故事会拆分成为用户故事，每个需求都被称为一个卡，卡是开发工作的最小单位，而每张卡建立起来之后需要所有开发一起对卡所需要消耗的时间进行估算（Estimation），所有人一起估算也是为了保证估卡的公平性。卡按照性质也分为需求卡（正常绿色）、故障卡（红色）和技术卡（黄色），其中技术卡主要是指重构、CI/CD等不属于客户需求，但是属于支撑开发或者提高开发效率的卡，这种卡也是算在客户的付费时间中的。

这里需要提到的是，一张卡估算出来的时间是按照开发全速无打断无切换的情况完成的，而最终这张卡交付的时间可能与估点时间不同，实际时间和估点时间的比率正是ThoughtWorks等咨询公司对于程序员自身成长的认可和鼓励，毕竟从理论上讲估点时间是所有开发共同估算的合理时间，开发有权利在完成客户需求的同时得到自身的提升，这点上后面有关自建团队和外包团队的区别也会提到。

2.4 Estimation/Kick Off/Desk Check/Sign Off

开发做卡的全过程，分为Estimation，Kick Off，Desk Check和Sign Off四个过程，Estimation阶段确定卡的时间，Kick Off阶段开发把卡所包含的内容和风险复述给BA和QA，确保开发已经完全明白了任务的上下文，而Desk Check和Sign Off则确保开发做完之后展示给客户的功能（经过BA和QA确认过眼神）就是客户想要的功能。整个功能这种独特的仪式感，其实也是敏捷之所以被诟病的原因之一。

一张卡的所有过程可以通过需求墙追踪，而建卡和卡每个阶段的更新也是开发需要做的极其富有仪式感的事情。

2.5 Retrospection

迭代回顾会是敏捷的另一个“富有仪式感”的仪式，每个迭代完成后团队所有成员总结上一周期的工作得失、发掘问题改进措施，进而推进团队下一周期的工作质量。这是很多业界大佬也都嗤之以鼻的仪式，但是这个回顾的最高指导原则，其实第一次读的时候有些感动，也恰巧代表了敏捷对于开发的含义吧：“无论我们发现了什么，考虑到当时的已知情况、个人的技术水平和能力、可用的资源，以及手上的状况，我们理解并坚信：每个人对自己的工作都已全力以赴。”

2.6 CI/CD

CI/CD，即持续集成/持续交付也是敏捷所倡导的能够提高响应速度和迭代速度的“神圣工具”，从代码编写完毕到生产环境的一系列自动化流程确保了开发提交代码之后能够以最快的速度上线，这让开发的工作能以最快的速度让开发成果展现在用户面前。

三、敏捷尊重劳动价值和劳动者，不适用于自激励的风险型团队

作为一名开发，体验敏捷最大的感受是，敏捷其实从根本思想上来说是一种尊重程序员劳动价值和自身发展的思想，有些时候甚至会怀疑这种尊重是不是来自于开发人员自身的孤芳自赏而暗自警醒，遗憾的是这种思想并不适合于当前国内劳资市场的大环境，不适用于很多公司的很多场景。

敏捷倡导的交付流程，与正常交付流程相比独特的环节是需求估算，这种需求所需工作量的大概估算的本意是帮助需求者（一般是产品经理或者客户）衡量该需求是否是真正值得的，同时也便于需求者按照工作的轻重缓急为程序员安排工作效率，这其中恰恰体现了软件开发的思维价值。

在承认了软件开发是一种脑力劳动的结晶的同时，敏捷也在天然给使用者灌输一种思维，那就是软件开发者的工作是有价值的，按照人/天的方式计算的工资赤裸裸的体现这一点，想要完成和交付某个需求就必须要付出若干人天的等待和费用。与此同时在很多敏捷的真实实践项目中，由于敏捷方法对于开发者的要求较高（别忘了还有结对编程这种烧钱的工作方式），很多情况下一些比较有人文关怀和科技视野的公司会在公司内部构建一种学习和进步的思维模式，内嵌在高质量完成客户需求这样的价值之中，并在潜移默化中劝服用户：“软件开发人员多花费时间学习和提升自己，正是为了能够给客户交付质量更高的代码”。这种思维模式认为软件开发人员在完成客户需求的同时，也应当在个人的能力方面有所提升，这也是敏捷所附带给程序员的蜜糖。

但是实际上很多公司组建的自有的研发团队已经使用月固定工资的方式买断了团队成员的月工作时间，用年终奖和晋升机制的方式约定了可预见范围内的人员稳定，而一般运行稳定的公司并不存在短期雇佣一帮程序员干一票就散伙的思想，软件开发人员从被雇佣开始就被认为将是长期工作在团队中的，在这种情况下软件开发并不需要细致到天级别的工作量估算，敏捷显得又些累赘而又形式化。

因此对于很多公司来说，敏捷的落地最后会缺少很多内容，往往公司会吸收敏捷的一些有利于提升工作效率的实践，而选择性得忽略一些敏捷内核优质的思想和文化，从而导致敏捷不伦不类，软件开发人员疲于奔命赶进度以“快速迭代”，管理者每天听取下级汇报然后讲话动辄三五十分钟也称为“站会”等等，本文这里无意探讨自建团队与外包团队的优劣，之所以举这个例子也只是为了说明敏捷其实更适合于没有狂热的进度追求和自激励的开发团队，更适用于一个有着技术追求和可持续发展方式的技术团队。

四、敏捷是一种自上而下实行的管理制度，而不是可以凭借共识达成的氛围

敏捷方法从根本上来说是一种可以用来管理团队的制度，哪怕践行者采用的是扁平的组织架构组织小而精的全功能团队，但是扁平化依然是对于老的管理模式的破坏。

敏捷要求的快速迭代最适合的团队规模是6到10人小团队，这个团队往往是一个全功能团队，BA/QA/Dev/UX在内的各个角色都要有，或者要身兼数职，这在对团队成员提出较高的要求的同时，也挑战了传统的团队管理方式。前面提到的敏捷之所以对于开发是蜜糖正是因为敏捷保护了开发的时间，确保一个完成交付任务的开发人员能够以正常的节奏和心力完成工作，同时能够保留属于一个脑力劳动者的个人时光，用于个人提升和生活。

敏捷虽然是一种包含了站会、迭代回归会和Kick Off/Sign Off在内的多种仪式感组合起来的方法论，它所具备的优势，依然是一种需要自上而下实行的管理制度，而不是一个经过粗略介绍进入团队就能根据共识达成的轻松的团队文化氛围。当然这里并不是说敏捷所形成的文化氛围不轻松或者沉闷，恰恰相反这种文化氛围相当具有张力和感染力，成型的敏捷制度能够很宽松得容纳团队成员的差异，并能够极大得激发团队成员的创造力和活力——这一点很容易被管理者注意到，认为敏捷是一剂肾上腺素，实施之后团队就能斗志昂扬，殊不知敏捷的时间并非易事。

敏捷盛行的这些年里可以看到的是很多公司的很多团队去尝试了敏捷制度，比如和笔者上份工作类似的自有团队，在等级森严、上下级分明的团队中实施敏捷，在敏捷文化内核的平等和价值之上人为添加了制度和阶级等无关紧要却有利于维持团队存在感的东西，并无异于敏捷的自有气氛蔓延。仅仅凭借Dev的共识而构建起的沟通和协作的气氛能够在Dev层面降低沟通成本、倡导自主学习，但是仅仅在某个环节的孤立敏捷（从实践上来看最没有阶层Gap的Dev往往最容易实现这种孤立的小团体敏捷）并不能突破其他层面的限制，比如说从BA层面的相应变化和识别价值，从PM层面的生命周期管理和风险控制，这些往往都没有得到较好的提升，因此敏捷实施只是形而上学而已。

五、全栈工程师：开发的死胡同和伊甸园

敏捷之下各个角色如何自处？作为一名也在经历个人选择的Dev的角度，我曾不止一次思考。

可以说在敏捷的整个流程中开发Dev作为软件价值的核心缔造者，本来就是敏捷规则中最关键的部分，哪怕是在敏捷中Dev和BA/QA/PM这样的角色合作似乎分薄了其光环色彩，但是敏捷也最大化得提升了Dev角色的人生体验。可以看到的是对于开发来说敏捷更期望的是开发都能是全栈工程师。

全栈工程师是几年前比较火的概念，顾名思义就是能够在软件开发的各个阶段都能打能抗的工程师，起初概念只是包括网站前端和后端，后来随着DevOps的一阵春风，全栈工程师也附带了基本的Ops技能。全栈工程师似乎成为了开发眼中一个理想的角色，能够适应任何工作的需求获得敏捷体系的认可。成为这样的工程师似乎是一件十分有安全感的事情。

但是实际上也有一种声音，那就是全栈工程师是万金油，成为全栈也是一条死胡同，成为一个行行都会的人，似乎就成为了一个行行都不精的人。在工作中也能够看到，从开发的角度来说，敏捷所提倡的开发是一种能够迅速实现客户价值的开发，在开发中常常借用的手段并非如同自建核心团队一样深刻钻研一个内存池、一个函数调用，花费多个迭代解决一个优化需求等等，敏捷开发似乎总是在拼接API或调用现有服务凑成一套能用的软件，恰恰如同敏捷宣言中所说的“工作的软件”的概念。在这种工作模式下的开发似乎很难积累技术的深度，和系统级的深入特性，毕竟缺乏了数年对于一个产品的精雕细琢似乎很难深入细节。

但是实际上从开发来说，开发从全栈工程师，或者从更广的维度，以交付价值为核心的开发工作，更可贵的收获应该是能够迅速响应变化的技术栈，不断保持学习的人生态度，这怕是全栈的蜜糖所在。