敏捷软件教练书单
AGILE沟通协作、敏捷技术、敏捷管理、心理学、引导技术、领导力、通用管理方面的阅读书单
自动化测试
TDD 自动化测试就是软件测试中的高铁。
在软件交付过程中，相信没有哪位客户希望错误被生产环境真实的用户发现。开发团队要尽可能降低错误流入生产环境的概率，并且越早越好。而且实践经验证明，发现问题的时机越早，我们修复问题成本就会越低。所以，及时发现软件问题成为了一个关键的因素。
及时发现问题，让问题能够及早暴露出来，如果团队无法有效快速的定位问题，难免镜中赏花不知花在哪。所以，快速定位问题构成了另一个关键因素。因为只有定位到问题，方可有的放矢。而无数软件开发实践证明，花在定位问题上的时间远远超出修复问题的时间。
所以，发现问题的速度和定位问题的速度是团队在做软件测试时需要关注的两个关键速度。要实现两个速度的提升，单纯依靠传统的手工测试是不够的。传统绿皮火车靠人工烧煤，速度怎么也快不起来，引入了全车箱电力动力系统后的高铁，速度发生了质的飞跃。
我的简单设计价值观
Simple Design 简单是一个成年人司空见惯的词，然而，大部分成年人却觉得纯真的孩子才是简单的。
很多时候，人们习惯把简单跟容易理解成一个意思。简单和复杂多用于形容事物或人的属性或状态，容易和困难一般形容达到某种目标的过程。生活中经常听到这样的感慨：「人活简单点真难啊！」、「系统一不小心就搞复杂了」。这些感慨背后流露出一种心愿 -- 保持简单。
作为有代码洁癖的程序员，我平时在工作中一直尝试对简单设计的理解和运用，本文中我结合了平时的敏捷工作来思考简单设计背后的价值观。
简单设计之揭示意图
Simple Design揭示意图，要揭示什么意图呢？袁帅尝试带你回到软件开发的本质，思考意图背后的东西，以及三种可以揭示的意图。
简单设计之消除重复
Simple Design重复一定要消除么？不一定，还是要看重复有没有给你开发软件和理解代码带来问题...
简单设计之识别重复
Simple Design你以为的重复就是指长得一样的代码么？然而，很多重复代码跟长相关系并不大，本文，袁帅带你透过外貌看代码，聊一聊6中重复。
简单设计五原则
Simple Design在我的简单设计价值观的指引下，本文我以代码设计面临的问题为起点，进而讨论设计决策中我们主要考虑的维度，针对这四个维度我们一起来尝试回答四个问题。 对于这些问题，我基于Kent Beck提出的简单设计原则，并结合当今的软件开发，做了一次全面的解读，最后通过价值延伸来诠释简单设计的魅力。
故事开发的首尾呼应术
AGILE如题，故事是用户故事，它是敏捷研发团队一贯采用的需求管理手段。开发人员以用户故事作为需求功能开发的单元，在开始开发用户故事前和完成用户故事开发后，一头一尾，通过两个非常轻量级的实践来形成首尾呼应，能够大大提升工作产出的价值，减少返工的风险和浪费。 本文重点聊一聊这两个轻量级团队社交实践，它们分别是 Story kick off 和 Story Desk check，中文通常被翻译成开卡和验卡，卡指的是用户故事卡。
细品Code Review
AGILE自从2015年3月加入ThoughtWorks接触到团队Code Review活动之后，我对Code Review有一种上瘾的感觉。那会儿的项目简直是敏捷派程序员的乐园，各种敏捷工程实践都得到很好的实践，团队了有优秀的程序员带着一帮热爱学习的新人和次新人在构建着已投入生产的大型商业软件。 我当时作为一名团队次新人，特别享受Code Review过程中去审视别人的代码，发现不良的设计，然后提供我的见解，当然还有机会吸收很多小伙伴的观点，而我的Clean Code的意识和基本功也因为这种Review会议得到加速提升，很多在书本上看到的一知半解的原则在这种思辨过程中得到吸收。Code Review活动让我吸收了很多营养的同时也展现了自己的价值，增强了自身的团队归属感。所以，以至于再后来参加了很多不同类型的交付项目之后，我都会格外注重Code Review这项活动，走到哪里我都会去主动推动这项活动。就像平板支撑，喜欢运动的我会带着大家一起在工作中运动，因为它确实能够为我们带来好处，Code Review也是如此。 我也碰到过交付压力大的团队，他们可能会节省下Code Review的会议时间，企图让大家每天多出个把小时来写代码，这样就也许能多开发点功能。而有的团队虽然没有取消Code Review，但流于形式，把Code Review搞成没有笑声的单口相声，大家聚到一块放松放松。还有的团队介于这两者之间，不想流于形式，但苦于团队优秀程序员的匮乏，导致效果不佳。 家家有本难念的经，每个团队的情况都不尽相同，Code Review为什么要坚持做？以什么样的形式开展？适合什么样的团队？这些问题的答案也是因团队而已，我的观点是：这是一项值得投资的活动。
远离无效的知识管理
AGILE-COACHING随着互联网的繁荣发展，信息传播的多样化和速度已经发生了质的飞跃，人们获取信息越来越容易，业界各类有识之士纷纷买票上车，大力向外界传播自己的知识，或是出于公益而免费普及，或是出于利益而付费变现。 在这样信息大爆炸的时代下，诞生了一个新的名词：知识焦虑。以至于一些网络人士给现在某些互联网知识平台定位为贩卖焦虑的平台。 作为程序员，暂且不必参合到那些舆论中，回到自己的领域，我们不得接受的一个事实是：在软件开发中，也充斥着海量的知识。比如，开发方法论、研发流程、业务需求、技术方案、系统架构、编程范式等等。除了这个事实，我们还不得不面对一个问题：软件研发中很可能会因为知识越多，反而越难行动。就拿困扰研发团队多年的文档问题来讲，那些在研发过程中制造了大量文档的团队，文档的维护无疑成为了团队前进的负担。 知识并不是越多越好，知识越有效越好。何为有效的知识？如果让我定义，我认为有效的知识就是那些能够被团队成员消化吸收，并进一步内化成认知的知识。所以，有效的知识消费应该要经历四个阶段形成闭环：生产-->传递-->运用-->吸收。生产的知识要被传递出去，知识接受者将知识运用到工作和生活中解决了问题，通过实践证明自己掌握了知识，这样才说明知识被有效吸收消化了，成为接受者的营养成分，内化成自己认知。
程序员的3种思维误区
Career在ThoughtWorks，我学到了对我的职业生涯来说很宝贵的东西 -- **用正确的方式做正确的事情，持续改进，追求卓越**。在一个这样充满同侪压力的学习氛围中，即便胸无大志的我也不会被潮流抛弃，顺流缓进是一贯的主旋律。流的越久，认识的程序员种类越多。总得来说，在这里大部分人在做正确的事情，同样也用正确的方式做事情。 阴差阳错，我从历时5年的交付项目上跳出来，成了一名技术讲师和技术教练。视角的切换方才后知后觉 -- 原来之前我是 不识庐山真面目，只缘身在此山中。接触到的程序员多了，发现虽同为程序员，彼此有大别。有的人喜欢沉浸在技术的乐园，唯业界先进或炫酷的技术尝鲜为快。有的喜欢追逐热点，忽视了枯燥反复的基本功修炼，深怕被时代遗弃。有的人则在这里谋得一相对高薪的差事，心猿意马，采用蹩脚的方式应付着各种软件的需求亦或要求，生活在水深火热中却不自知。 我也遇到了我欣赏的一类程序员，他们始终孜孜不倦地修炼自己的基本功，始终在思考什么是正确的事情，不断地尝试跳跃出自身的局限性，能够耐下性子跟时间做朋友，不断遇见更好的自己。我在他们身上看到了三种有益的思维模式，在这种思维模式的指导下形成的工作习惯让他们在工作中脱颖而出。
Mocks 不是 Stubs
AGILEgMock对象已成为一个流行的术语，指的是在测试中模拟真实对象的一类特殊对象。现在，大多数编程语言都有可以轻松创建模拟对象的框架。但是，人们通常没有意识到的是，模拟对象只是特殊场景下测试对象的一种形式，它支持不同风格的测试。本文将会介绍Mock对象是如何工作的，它们如何推进基于行为验证的测试，以及社区是如何使用它们来开发不同风格的测试。
《你只是看起来很努力》些许感想
Career前段时间看了《你只是看起来很努力》，书中没有头衔家族（心理学家、科学家、哲学家等）那些成体系的理论知识和指导框架，更多的是作者自己一路走来经历的故事，这些故事主要写的是别人。他通过这些故事来参悟一些人生道理，并试图以自己的言语传播。有的人也会视之为鸡汤，这不重要，重要的是它能不能跟跟你产生有效的共鸣，并带来积极的影响。
简单聊聊契约式设计（下）
DbC在上一篇文章中通过里氏替换原则的示例，Bob大叔抛出了一个观点 – 做模型设计的时候，要基于客户程序使用的角度去审视模型的有效性。这就需要我们要去猜测客户程序的一些”合理”的假设。当一个事情需要靠猜测的时候，我们总会觉得心里不安。Bob大叔提到DbC这项技术，能够帮助我们来明确用户的合理假设。本文来聊聊如何借助DbC的设计思想来加持LSP。
简单聊聊契约式设计（上）
DbC我在阅读Bob大叔的《敏捷软件开发：原则、模式与实践》第十章的时候第一次接触Design by Contract这个概念。Bob大叔在讲述面向对象设计SOLID原则中的LSP(Liskov Substitution Principle)时，就借助DbC的设计思想来支撑LSP[1]。关于DbC，我将用两篇文章来简单聊聊。
SOLID entrepreneurial story of Mr. Object-Oriented
Object-Oriented Design After doing so many years of Object-Oriented programming, I still write code that violates the SOLID principles. I understand it at a glance, but am embarrassed when coding. The understanding of SOLID is not enough. What should I do?
SOLID principles are usually abstract, Even developers experienced in OO may not have a solid grasp of the SOLID principles, let alone those new in OO.To improve the sensitivity to SOLID principles, the first step is to be clear what are each the principles. In this article, Mr Yuan's SOLID entrepreneurial story will unveil the principles.
听面向对象先生聊SOLID创业故事
Object-Oriented Design 做了这么多年的面向对象编程还是写出违背SOLID原则的代码，对这些原则不敏感，看过一遍又一遍，还是会忘记，经常在Code Review中被怼，如何是好？难到SOLID原则本身就有错？难道我不应该涉水OOD？
原则通常较为抽象，别说刚接触OO的程序员，有一定经验的人也不一定能吃透。要想提高对OO原则的敏感度，第一步，我们要清楚SOLID到底在讲什么？本文，袁Sir的SOLID创业故事将为你揭开一层面纱。
在ThoughtWorks，希望你知道的Feedback
CareerFeedback作为名词，可以理解为一种信息载体，该信息通常承载了认可或建议。 Feedback作为动词，指提供反馈或接收反馈，是一个人向外传达信息以及从外部接收信息的过程。 在ThoughtWorks，Feedback的重要性犹如发动机于车，像Interview、Interview++、Probation Review、Quater Review、Annual Review等重要绩效考核环节无不都在依靠Feedback这架发动机来推进。操控这架发动机的是每一位TWer，一群TWer在一起凝聚成独特的气场，久而久之沉淀成一种文化 -- 扁平文化。 扁平组织弃用了传统的KPI绩效考核，而绩效考核关系到每个员工的职业发展，这让Feedback的意义尤为凸显，如何做好Feedback（动词）以及如何鉴别Feedback（名词），可以说是每一位TWer加入ThoughtWorks的第一门必修课。 我认为，好的Feedback需要具备三个基本的属性...
超越培训 -- 比培训多做一点点
AGILE-COACHINGThoughtWorks武汉Office服务于海外知名大企业的某Account，因为高质量交付赢得客户的信任，并被视为敏捷技术标杆，供其他Vendor效仿学习。业务合作机会的增多促使团队进行Ramp-up，原本新人占比大的现状伴随着Ramp-up继续加剧。如何保持良好敏捷技术实践、实现技术卓越 成为团队即将面临的一大难题。新机遇所带来的挑战对团队提出了更高的要求，促成了思沃内训团队和该Account的姻缘，强强联手打响了一场持久的训战。
聊聊面向对象设计中的Is-A
Object-Oriented Design 面向对象编程范式得到了广大开发者的青睐，在做面向对象软件设计的同仁也或多或少曾经心存困惑过。比如，怎么样才是正确的封装？如何恰当的继承？何时应该抽象？ 对于设计，我们很难说对与错，通常只有好与不好的区分，而所谓的最佳实践也只是 -- 在当前约束下，人们所能找到的最佳解决方案。
最近我在给ThoughtWorks内部某海外交付团队的核心成员（Tech Lead & Second Tier）做OO Bootcamp的培训，在分享讨论和编码实践的过程中加强了对面向对象设计的理解，本文我来聊一聊面向对象中关于继承设计的`IS-A`的这个工具。
让里氏替换原则为你效力
Object-Oriented Design从事软件开发的朋友或多或少都听过以下一些原则：比如KiSS、DRY、LKP、COC、DbC、SoC、HP、SOLID等。这些原则已经在业界被证实了自身的价值，尤其当谈到面向对象设计的时候，SOLID则是一个避不开的主题。 对于大部分OO程序员，这五大原则的名字可能已经耳熟能详，却总不能很清晰的描述出SOLID是如何为我们服务，因为SOLID从来也没有告诉我们How，它只在说：'这就是你最终要达到的目的地'。 本文我将带着我的思考来捋一下LSP，LSP可能是一个很容易被破坏的原则，理解了它将能够很好地驱动我们去思考如何正确地做抽象设计。
Scrum团队的两个基本元素
AGILE-COACHING在瀑布模型的IT组织中，试点团队一旦决定采纳Scrum，就如同开启创业。对于创业，我们喜闻乐见的是：有人有想法、有抱负、有激情也有行动力去推动变革，做不一样的事情，此时，Ta或者Ta们会试图去寻找志同道合的人，寄希望于通过团队来提高成功的几率。 就好比软件永远无法甩掉`业务不确定`的天然属性，Scrum团队自然也脱离不了创业团队的属性。高战斗力的团队会具备两个基本的属性：自行和志同
深入解读敏捷宣言
AGILE我相信接触过敏捷软件开发的人或多或少了解过敏捷宣言。敏捷宣言第一句告诉我们敏捷方法论并不是凭空而谈，它源自于截止目前的实践积累， 敏捷宣言的最后一句起到画龙点睛，它在强调敏捷方法论源自于实践。它要能够回归实践，帮助我们解决实际问题，而不是一个框住我们思维的框架，沦落为思想牢笼。所以在实践中，我们应该以什么样的心态去对待敏捷呢？ 本文我将结合我的实际项目经历尝试对敏捷宣言做一个深入的解读。
从写代码到做培训
Career作为一枚程序员，我埋头写代码到了第五个年头，走过很多弯路却发现是一个个填坑、挖坑过程，尝试很多东西后却发现仍然停留在`看是不是山、看水不是水`的状态。在这个转角上，个人初衷加上客观形势，我踏上了培训的道路，开始不断地尝试去梳理、总结、分享。 在培训道路上，我看到了不一样的风景，新生了一些疑惑，产生了一些对未来的思考，本文我将分享一些我从写代码到做培训后的心里路程。
简单设计落地三板斧
Simple Design假如让你去建造一幅巨大的广告牌，你会怎么做？从大框架来看，首先要打牢地基，再使用结实支柱做支撑，最后在顶部挂上广告牌。地基和支柱是帮助完成目标的必备条件。那么，如何实现简单设计的核心价值？我们可以以简单设计价值观、简单设计原则做为地基，并通过打造TDD、重构 和 整洁代码 三大支柱来支撑起简单设计的 '广告牌'。 本文我将分享帮助我们落地简单设计的三板斧：TDD、重构和整洁代码。
Workshop中的价值交付投射模型
AGILE-COACHING做任何事情之前，我们都要考虑其背后的价值，定义清楚价值，如何去实现价值，比如在这里我们如何通过Workshop达到这些目的。为了促成最终的交付，我们还要考虑影响交付的一些外在因素，最后，在成功交付之后如何将我们所交付的价值持续产生更多的价值也是等待我们去思考的。 本文作者带着自己的思考，提炼出了一个价值交付投射模型，并针对这个模型提出了一些操作层面上的问题，最后通过敏捷开发中的Sprint来梳理了解决问题顺序...
微服务实战训练营
Micro-Service微服务实战训练营。依托真实大型微服务项目为载体，旨在通过工作坊的形式提升团队人员驾驭微服务的能力。
轻描淡写的2017
Career2017年，主旋律，忙。可自己还是不满意最后的结果，并不是我不知足，是因为我觉得自己还不够努力… 磕磕碰碰中，我收获了三个对我来说意义重大的词汇：自信、健康和自律。之所以对我来说很重要，是因为我还处在匮乏的状态。不一样的是，我更加深刻地体会到它们背后的意义。
从另一个角度告诉你单元测试的意义
AGILE AGILE-TESTING 微服务架构带来的复杂性（右边部分）已经很大程度上得到了解决，常见的解决方案是在开发团队中植入DEVOPS。比如在ThoughtWorks中的某些团队，DEVOPS成为Team不可或缺的成分。
我们把注意力放在左边部分。开发人员关注更多的是`开发`，每个服务由一个小的Team负责开发，Team正在极力往`服务自治`的方向靠拢。测试人员可能更加关注`测试`，尤其是契约测试伴随着业界对集成测试（UI测试）的痛斥声而崛起。`消费者驱动契约测试`的演讲比比皆是，我也没有例外，在某Account的技术大会上做了一次 *微服务架构下的测试应对策略* 的分享。在分享中，我赶时髦提倡用契约测试取代集成测试，但是细节中没有忽略的一个核心点：*单元测试*。这也是本文我要分享的重点。
ThoughtWorks给你不一样的入职之旅
CareerThoughtWorks是一家极具创造力的公司，在这里，人才是最重要的资产。如果你以应届生的身份加入TW，你将获得出国留学5周的机会（TWU培训），如果你通过社招加入TW，你会获得为期三天的TWI培训。除了TWI、TWU，公司还提供诸如NHO、Session、Workshop、Buddy/Sponsor、TL、极光计划（领导力）等数不胜数的培训。所有这些培训让你的的职业之旅变得不一样。
而更不一样的是，这次，TW北京Office联手思沃学院推出了一个Local项目人才培养计划，针对某Local项目刚刚入职的5位新人（应届生）进行`封闭式`脱产培训。旨在通过为期四周的高强度培训，帮助新人快速融入到项目中。作为Coach，我来说说它到底不一样在哪里。
受思沃学院 以学习者为中心的教学 启发，我给此次培训起名为 《以学习者为中心的项目驱动培训》，一来培训目标很明确 -- 新人更好更快地上项目实战，二来以项目为驱动力的培训是一种强有效的能力培养方式。
以学习者为中心的项目驱动培训
AGILE-COACHINGThoughtWorks北京Office和思沃学院联手推出了一个Local项目人才培养计划，针对某Local项目即将接纳的5位新人（应届生）进行'封闭式'脱产培训。历时四周左右的高强 度培训，新人已经顺利加入项目。作为Coach，我想分享一些关于此次培训的经验和心得。
受思沃学院*以学习者为中心的教学* 启发，我给此次培训起名为 *以学习者为中心的项目驱动培训*，一来培训目标很明确 -- *新人更好更快地上项目实战*，二来以项目为驱动力的培训是一种强有效的能力培养方式。
微服务架构下的测试应对策略（下）
AGILE AGILE-TESTING 微服务架构解决了单体应用的痛点，打破了SOA的瓶颈，同时也带来了很多的复杂性。部署运维方面，服务的部署、管理、监控。开发设计方面，服务的拆分、设计、编码、测试都将会变得复杂。幸运的是，容器化技术（比如无比流行的Docker）已经很大程度上帮助我们克服了环境的差异性，而一些容器编排工具诸如Kubernetes, Rancher, Docker-compose 提供了容器部署管理的解决方案。作为行业的领航者，ThoughtWorks也在极力倡导 开发、设计、部署、运维一体化 的DEVOPS文化理念，并通过丰富的咨询和交付成果来帮助企业研发团队更好地实施微服务架构的开发。
那么在编码测试方面，又有什么新招来保证微服务架构下系统的质量？
本文接着上一篇来阐述消费者驱动契约测试。
微服务架构下的测试应对策略（上）
AGILE AGILE-TESTING 微服务架构解决了单体应用的痛点，打破了SOA的瓶颈，同时也带来了很多的复杂性。部署运维方面，服务的部署、管理、监控。开发设计方面，服务的拆分、设计、编码、测试都将会变得复杂。幸运的是，容器化技术（比如无比流行的Docker）已经很大程度上帮助我们克服了环境的差异性，而一些容器编排工具诸如Kubernetes, Rancher, Docker-compose 提供了容器部署管理的解决方案。作为行业的领航者，ThoughtWorks也在极力倡导 开发、设计、部署、运维一体化 的DEVOPS文化理念，并通过丰富的咨询和交付成果来帮助企业研发团队更好地实施微服务架构的开发。
那么在编码测试方面，又有什么新招来保证微服务架构下系统的质量？
本文将从开发测试的视角来探讨如何在微服务架构下通过不一样的测试策略来尽可能的保证系统的质量。
一枚程序员眼中的单元测试
AGILE AGILE-TESTING如今程序员群体赶上了中国最庞大的农民群体，大街上随便抓一把，十有八九是程序员，还一个刚从某国企离职报名参加软件培训班。我想码农的称号或许就是这么来的吧。
在外行人看来，程序员是一个成天对着电脑倒腾着代码、看着Terminal上行云流水般的打印、过着不修边幅的日子外加超负荷的码农。
在内行人看来，程序员是一个成天面对QA的”质疑”、PM的”夺命催”以及DEVs的”吐槽”，扛着身心压力的苦行僧。
改善程序员生活质量的 3+10 习惯
Career程序员的工作性质决定了这个群体面临着一些问题，比如久坐引起的颈椎和腰椎疾病。身为ThoughtWorks的一名程序员，也难免长时间与电脑为舞，为了规避这些问题，自己通过长期养成的一些习惯来改善自己的工作效率和生活质量。 能够改善我们生活质量的并不是什么高深的奥秘，恰恰是一些小小的习惯。文本以黄帝内经中提到 "食饮有节、起居有常、不妄作劳" 三个方面为引子来阐述饮食、作息和运动方面的重要性，通过加强对它们的认知，配合一些良好的习惯，从而提升程序员的生活质量。
重构十六字心法
Refactoring这篇文章是我写过的所有文章里最难产的一篇，前前后后斟酌酝酿了好几个月。因为重构对于我来讲真的太重要也太深刻了，包含的内容和想说的也太多了。如果说这几年自己觉得在哪些方面的收获最大的话，非重构莫属了。
使用Raml构建Restful API
Web Development当下微服务架构的流行趋势下，一个项目或多或少被拆成多个小的服务，服务于服务之间主要采取RESTFul API进行通信。而新衍生的问题是：一个开发团队按照服务被分成多个小的Team，如何有效管理服务之间的API契约？ Raml为我们提供了解决方案。本文以一个共享图书馆的例子，针对Raml的几大特性，从API的设计、API的构建、API的测试、API的文档化到API的分享来讲解API的使用，并结合容器技术来构建一个API的基础镜像。
写给新人的一封信
Career最近工作和生活中发生了一些事情，正值一年毕业季，回想起自己从校园到职场的过渡，也曾有过许多迷茫与困惑。而今已经踏入软件行业四年，自己也积累了一定的经验与认知，因此想要给想要进入这个行业以及已经身处其中的新人们分享一些Tips。 新人包含在校的科班/非科班学生、半途转向培训班的培训生以及正在纠结于是否要进入软件行业的弟弟妹妹们。当然，这其中还包括一只脚已经踏进软件行业，却心存迷惘的探索者，正如2013年的我。
ThoughtWorks，我的2016
Career作为一名ThoughtWorker，追求卓越，为公司和可客户创造价值始终是第一目标，当然还有一个并列的第一个目标是：提升自我，实现自身价值，而这些都胜不过 让世界变得更加美好 的伟大愿景。用一句广告语讲就是：因为你，世界便多一份美好。所以，ThoughtWorker不会忘记初心，始终坚守在追求卓越的战线上，直至趴下。 说得有点壮士断腕的感觉。这让我想起面试时郑烨问我的那个问题：当你发现你所遭遇的场景并没有你想象得那么理想时，你会用你自己的努力去改变着它，让它走向卓越吗？ 虽然看似一个选择的，甚至不用动脑筋都能回答 会，可这一个字包含了太多的意义，而这一年我也深刻感受到了其中的滋味。什么滋味，这就要深入到2016年实际工作中来
ThoughtWorks中的敏捷团队建设
AGILE AGILE-TEAM主导项目成功交付的核心因素还是人，以人为本 在软件交付项目团队中也是非常适用的。在ThoughtWorks，唯一相同的是每个人都有独自的个性和特长，那么这些有个性的小伙伴们是如何良好地在一个团队中工作的呢，除了大家比较强的自我管理能力之外（对TW的价值文化的认同，自我管理和自我驱动力较强），也需要有意识的搞一些团队建设工作，特别是Team Leader(PM, TL)要兼顾团队建设方面的职责，思考如何让团队更快地成长起来，以及营造更融洽的团队氛围。
我在ThoughtWorks中的敏捷实践
AGILE AGILE-DELIVERY敏捷开发的核心就是在一个高度协作的环境下，不断的通过反馈来进行自我调整和完善。重点强调的是 协作 和 反馈，协作体现在团队与客户之间的协作，团队成员之间的协作。反馈则是在开发中的任何环节，包括代码质量、自动化测试、部署、项目进度、需求变更、客户验收等，而且反馈越快越好。有句土耳其谚语这么讲的：不管你走了多远，错了就要重新返回，所以我们越快得到反馈，就能越早确认自己有没有走错路。如果没有错，我们会更加充满信心。反之，及时做出调整，让浪费最小化。 本文以我在ThoughtWorks中的E项目经历为依据，覆盖了ThoughtWorks日常独立交付项目中主要的敏捷实践。
Buddy/Sponsor培训•信任的构建
CareerBuddy，正如这个词的意思，小伙伴，好朋友。记得加入ThoughtWorks的时候，大家在公司内部的Session和微信群里喊的最多的是小伙伴。慢慢地我发觉一个现象：几乎每个人都把同事当成自己的小伙伴，大家相处很友好，互帮互助，整个氛围像个大家庭。试想一下，一个刚加入TW的新人，对TW的组织文化和做事方式充满好奇，自己的定位和发展还很茫然的时候，这时候ta被告知：Hey，你不孤单，你有一个小伙伴，ta将伴你度过半年的试用期......。陪伴，不仅仅是存在这个小伙伴，而且小伙伴要对你的成长负一定的责任，指导帮助你更快的融入到这个大家庭中来，让你成为一名合格的TWer。 Sponsor，这个词的含义有点意思了，赞助商？保证人？貌似都不是，赞助什么呢？要赞助也是公司给你赞助。保证什么？保证你不会离职？所以单从中文意义上讲，好像不是很表意，将它理解成负责人更确切一些。对于一个在ThoughtWorks顺利度过半年试用期的TWer来说，此时证明你已经是一个合格的TWer，接下来，你需要一位能够在你的TW职业生涯中给出有效指点的帮助的人，Sponsor对你今后在TW的生涯成长中负有一定的责任，帮助指引你朝自己想去的方向发展，成长为更好的自己。
初次做技术领导的3个陷阱
Career开发人员初次走进技术领导（后文简称TL）这个角色的时候都是很困难的。即便经验再丰富的开发人员，他的技能和经验也是不能自动转换成一个TL必备的技能的。事实上，如果开发人员不能很好地运用已有的技能和经验，或者不能在这个新角色中树立更多权威，一些旧有的习惯不但没有帮助，反而会带来阻碍。 这篇文章，我们一起来探索一下初次做TL时容易踏入的三个陷阱，以及他们可以做些什么来避免绕过这些陷阱。
高效技术领导的5个锦囊妙计
Career成为一个技术领导者(后文简称TL)对任何开发人员来讲都是一个艰难的转型，因为开发人员的经验和技能仅仅只有部分有助于他们达到对这个新角色的期望。除了简单的设计和编码，TL最重要的职责在于管理整个开发团队，这意味着TL要经常与技术人员以及非技术人员进行沟通协作。 一个开发人员花在编写良好结构的代码的时间并不能等效地转化成一些必要的技能，比如了解他人，解决冲突，以及突然需要同时处理多个他们自己并不太可能独立搞定的任务。本文分享一些初次做TL的人Tips，以帮助一个新人更好地胜任TL。
重构七宗罪
Refactoring重构经过了十几年的发展和应用，可以说它是极限编程中程序员最爱的实践之一了，纷纷争相在项目里应用。重构工作坊、Codekata重构练习等各种提升能力的方式也屡见不鲜，帮助程序员们去追求优秀的代码和设计。然这仍然摆脱不了人们对它的各种抱怨：“搞什么，又重构”，“重构出defect来了”，“项目紧，最近不要再重构了”，“重构到什么时候停呀”。小菜也这样被项目中的人抱怨着，觉得很委屈，找到了大牛小明。
ThoughtWorks，我的2015
Career2015年3月26日，我正式加入ThoughtWorks，这一天，我内心充满了喜悦，也多了几分压力，我的ThoughtWorks之旅在就我憧憬了一年后真的开始了。那么2015年3月26日之前，我在哪里呢？一笔可以带过：和朋友创业失败，过了本命年的春节后，我再次来到ThoughtWorks西安办公室，招待我的还是美丽及气质不凡的HR唐丽娟。就这样，一个星期过去了，在2015年3月26日那天，我跟ThoughtWorks签了终身合同。重要的事情说三遍，重要的日子也出现了三遍。 一年过去了，2015，我在ThoughtWorks经历了不一样的一年，感恩！