TW的工作方式逐字稿

work

开篇

各位同学，大家好，我是鄢倩，来自成都办公室。除了名字有些特点，其它方面没有太多亮点，简单记住我的名字就好了。我从毕业入职ThoughtWorks已经差不多5年了，做过国内交付，海外交付，在高大上的咨询团队做过2年多的技术咨询，现在主要在区块链小分队扩张公司的区块链业务。

所以这些经验倒也能支撑我来谈谈ThoughtWorks的工作方式。

但是我稍微想了想【思考中大卫】，你们来TW自然就知道了。

入职后会经过一个多月的TWU的教学，你们可以全天候，多角度，国际化地知晓TW的工作方式。而且，一般公司会分配你们到一些海外项目上，跟着有经验的团队一起工作。所以我有必要讲这个话题吗？当然，这也是一个先有鸡还是先有蛋的问题。

话还是得讲，但是套路得换。

工作时间

【955?】 996.ICU被955一锤子锤破，一个问号进入。

这段时间Github上讨论火热的996.ICU把很多大公司的加班顽疾给暴露出来了我们公司绝对不实行996，这点我倒是觉得任何时刻都能站得住脚；然而我们惊奇地发现ThoughtWorks上了955工作时间的公开列表，之所以表示惊奇就是因为我压根没听过我司有过这项规定。我承认在ThoughtWorks工作，时间是相对灵活的，我们从不鼓励加班文化，我们鼓励高效的工作效率和协作方式，在我的团队我甚至还劝告加班是一种“无能”的表现。但是955从不是我们的目标，我们的目标是高效地完成任务，自由地学习感兴趣的知识【955删除之，渐入“高效、自由”】，所以忘掉955这个标准吧。

工作方式

核心思想

我总结我司的工作方式，其核心思想就是两句话：缩短反馈、持续改进，这两句话看上去很简单，但是必须在开放、分享和学习的氛围中才能有成效，而TW正好提供这样的环境。ThoughtWorks是一家以敏捷软件开发著称的公司，市面上有很多实施了敏捷软件开发公司，不过TW的最大不同就在于一个字：真。我们并不会生搬硬套形式，而是围绕上面的理念自然形成一套工作流程。以我咨询师的经验，在我给团队实施落地敏捷软件开发过程中成功率是很高的，因为我可以把流程裁剪到适合他们当前状况的程度，然后让团队逐步成长到成熟阶段。这种思想会贯穿我们工作的所有活动当中，包括待会要讲的敏捷四会、持续集成、测试前置、安全内置，精益迭代等等。其实讲完工作方式的核心思想，下面的内容就显得不那么重要了，意思就是能记住多少是多少，记不住也无关紧要。

工作流程

刚加入ThoughtWorks的时候认识到开发团队除了开发和测试（当然这里我们认为是QA）外，还有BA ——业务分析师。10年前这个角色在和任何客户合作的时候都需要解释，当然现在大家都已经在开始谈论UX和DevOps了。全功能团队这个实践本身并非是说要固定哪些角色在开发团队，而是强调为了交付软件所需要的技能都应该在一个团队里。

我们回忆一下标准的软件开发的流程。大概分为需求，设计，开发，测试，部署和运维几个阶段，往往整个流程需要半年甚至几年的时间跨度。依照缩短反馈的思想，这个跨度太长了。所以我们把这些流程的时间缩短到1-2周，这1-2周的时间被称为迭代（iteration），每个迭代我们只开发部分高优先级的需求。

不过，虽然跨度缩短了，但是反馈没有形成，也就无从改进。即便是1-2周时间包含部分功能的软件产品上线了，结果用户气急败坏，客户撇着嘴抱怨这个功能不是我想要的对于我们而言也是不可接收的。所以我们需要设置检查点。

需求需要澄清，所以我们会在每次迭代前启动一个迭代计划会议（需求澄清会议），在会议上，我们团队的所有人都会和客户坐到一起，仔细地描述产品的功能点，或者用我们的话说是用户故事，也会包含软件安全故事；我们知道软件设计和需求是分不开的，设计在需求澄清阶段也会部分地以任务分解（Tasking）的方式验证，然后以用户故事点的形式进行估算；进入开发阶段之前，我们增设了kickoff环节，这个环节下BA、QA和Dev会坐到一起再次澄清需求的理解，又一个检查点。开发过程中会有TDD、结对编程、单元测试、重构来自己检查完成与否；测试一般发生在开发完成之后，但是我们设置会在需求澄清阶段就把测试人员引入讨论，在开发结束时提前在开发的本地机器上做验收，基本上到测试时交给QA的任务已经不多了，他们要做的是以更加严苛的态度和诡异的操作手法探索系统潜在的bug；部署阶段，我们有infrastructure as code，所有的运行时环境都可以脚本文件的方式从零启动，所以这些环境是不可变的，不可变性带来验证的简单，我们完全可以写部署脚本的测试脚本，先一步验证其正确性。而且为了验证需求的正确性，每个迭代结束后，我们会给客户演示这个迭代可工作软件的功能，甚至客户也可以自己操作，这又是一个很重要的检查点。进入运维阶段，我们会去做监控，日志采集，异常报警等等。

这些小圈，大圈形成的反馈环形成能帮助我们意识到问题存在，但是如何做到持续改善呢？持续改善的方法也有很多。有些通过沟通就能解决；而有些需要可视化出来，比如你们看到的卡墙，CI服务器。及时挪卡，及时修复挂掉的CI服务器，这些动作就是标准实践，内化的逻辑其实就是用于改进软件；还有些需要专门的会议揭露和修正，这里面就有每日站会和每个迭代结束后的回顾会议。每日站会提供了一种固定的渠道，让团队里每个人分享自己的工作内容，遇到的阻碍请求别人的帮助。回顾会议意义重大，它能帮助理清这个迭代中团队做的好的和不好的地方，以及各方面的疑惑。所谓有则改之无则加勉，我们总会制定出举措让团队朝更好的地方前进。顺便提一句，前面提到的迭代计划会议，产品演示（showcase）和这里提到的每日站会及迭代回顾会议是我们口中的敏捷四会，区别于Scrum四会。

缩短反馈和持续改善的差不多的同义词是快速验证和快速试错，其背后的科学依据大概就是科学的本质方法论：证伪。

上述的就是ThoughtWorks的工作方式，但是这就是足够好的工作方式吗？遗憾地告诉你，这并不是ThoughtWorks工作方式的全部。我们用正面的视角去看这个流程，会理所应当地认为它是一个正增强回路。但如果前期的输入一开始就是错的，这反而是一个负反馈回路。其中的差异就是正确地做事和做正确的事之间差别。

价值驱动

价值驱动是关键。想想我们为什么要把客户，BA，QA和DEV放到一起去开需求澄清会议？这不仅仅是为了避免间接交流导致的信息失真，还是为了让每个人都知道每个需求背后揭示的价值。如果某个需求对于客户产品面向的用户群没有任何用处或者用处极小，我们就应该明确地告诉客户：你的需求是错的。我希望各位加入TW之后也能有这样的勇气敢于对客户、PM和Team Leader提出这样的观点，因为这是TW的文化。

不过，价值驱动可能会导致一种极端认知，客户的利益是最重要的，所以我们作为专业服务公司应该尽可能满足客户的期望。这势必会损耗我们自己的力量。有必要澄清：价值驱动只是文化天平的一端，另一端就是誓死捍卫的技术卓越。

技术卓越

什么是技术卓越(tech@core)？技术卓越表现在很多方面，比如：内部质量不可妥协。TDD一定要做，重构一定要做，技术债一定要清除；推崇整洁代码；争论编程范式的适用场景；争辩Angular、React、Vue和PWA孰优孰劣；我就是要做linux内核、区块链底层开发等hardcore。你应该尽力推行你推崇的技术，不论是给技术雷达提blip还是自己写洞见或是说明团队使用在项目上，这些做法在公司内部是大力鼓励的。技术卓越作为3Pillar的一支一直是我们技术人员的执着，管理者甚至是客户也被要求对团队在追求卓越做出的贡献给予肯定。

所以总结下来，价值驱动和技术卓越是TW的核心文化，而缩短反馈和持续改进是原则，敏捷四会、持续集成和持续交付是实践。

TW的工作

上面的大图基本涵盖了TW关于软件开发的思路。Discovery，PoC，Inception和迭代交付。

Dicovery会帮助客户找到围绕其业务可以改进的点或者创新idea；快速通过PoC（概念验证）进行解决方案和需求的验证；然后快速进入Inception做用户访谈，用户画像，用户旅程，用户故事，迭代计划；进入交付阶段，下面的事情大家就都知道了。

最后，建议大家加入之后，一定要尝试把TW的实践从discovery一直做到delivery，感受始终。

推荐阅读

咨询Leader的20年回顾：https://insights.thoughtworks.cn/thoughtworks-agile/
硝烟中的Scrum和XP
敏捷软件开发-原则、模式与实践

ThoughtWorks是一家以敏捷软件开发著称的公司。ThoughtWorks一直在进行一场软件行业的革命。

共产党宣言

一个幽灵，共产主义的幽灵，在欧洲游荡。为了对这个幽灵进行神圣的围剿，旧欧洲的一切势力，教皇和沙皇、梅特涅和基佐、法国的激进派和德国的警察，都联合起来了。

敏捷宣言

2001年犹他州（Utah）的雪鸟城（Snowbird）

个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。

结尾

共产党人不屑于隐瞒自己的观点和意图。他们公开宣布：他们的目的只有用暴力推翻全部现存的社会制度才能达到。让统治阶级在共产主义革命面前发抖吧。无产者在这个革命中失去的只是锁链。他们获得的将是整个世界。

于2019年4月