深入核心的敏捷开发：ThoughtWorks五大关键实践

很多年前刷职场论坛时，看到有人分享ThoughtWorks的敏捷实践案例，我逐字逐句划重点——那时它是我心里“技术人理想栖息地”的代名词，最后阴差阳错进了另一家外企，看着朋友圈里很多前同事晒的TW团建、技术分享，心里总还是有点“未竟的遗憾”。 后来职场越走越久，见多了“挂着敏捷名头”的项目，也听够了“每日站会走形式、迭代计划拍脑袋”的吐槽，面试过好多TW的应聘者，再提起TW时，当年的“光环滤镜”慢慢淡了——好像它也只是外包公司里的一家，没那么“特殊”了。直到最近翻到《深入核心的敏捷开发：ThoughtWorks五大关键实践》，才发现自己有点“以偏概全”。 这本书没讲什么玄乎的理论，全是TW十多年实战攒下的“干货”：测试驱动开发怎么避开“为了测试而测试”的坑、持续交付在中小型团队里怎么落地（不是非要搭复杂的自动化流水线）、全功能团队怎么解决“开发甩锅测试、产品甩锅技术”的内耗……甚至连“敏捷转型到一半推不动”的窘境，都给了具体的应对思路——不是喊“大家要拥抱变化”的口号，而是教你怎么从需求拆解、技术选型、团队协作三个层面“软着陆”。 当然也有缺点。比如部分偏向大型企业的数字化转型的案例，对初创团队来说参考性弱了点；有些技术实践的细节讲得比较浅，想深入学某块内容还得再找专项资料。但作为一本“敏捷入门+避坑指南”，它足够实用——尤其是对刚接触敏捷、或者正在项目里“踩坑”的人来说，能帮你快速理清“敏捷到底要解决什么问题”，而不是陷在“要不要做迭代评审”“站会该开15分钟还是20分钟”的形式主义里。 当年追的“光环”真的淡了，但TW沉淀下的敏捷实践，依然有值得借鉴的地方。如果给这本书打分，我会给7分：不包装概念、不贩卖焦虑，只把真正落地过的经验拆给你看。 如果你想找本“不绕弯子”的实践手册，这本书值得花几个小时略读一遍，就当听一家有经验的公司，聊聊“当年我们是怎么把敏捷做起来的”，说不定就能从某个案例里，找到自己项目里的“破局点”。

我们做数字化转型敏捷实践已有近5个年头了，刚好leader也是从ThoughtWorks出来的，看了这本书有了更深的体会，为啥当初的很多流程与方法是必要的，愿景，目标，价值观，技术追求卓越，TDD。这些理论实践使我们迈进敏捷高效能团队更进一步。 推荐此书，但是对于没有进行敏捷实践的人来说此书的很多阶段与使用的方式方法难以理解，如果是刚接触敏捷开发管理的人推荐你们先读 敏捷革命 这一本书。

这是一本最新刚出的书，从内容提炼的角度和高度 到痛点总结都是特别的触动神经！贴近实践，有问题也有方法。唯一感受不好的是，章节是多人完成的，有点拼凑感。可能也是文笔风格不一致的原因吧。所谓拼凑不是凑合的意思。聪文字内容，感受到 确实都是大牛，更何况出自骚窝！强烈推荐！很开心，敏捷领域，终于有更多面向实践过程具体问题的剖析和解决引领！给五星！

哪怕到今天来看都是很不错的一本技术“炉边谈话”，不要尝试在这本书里找一条逻辑线，他不承担这项职责，而是应该看为什么他们选择这样做，这样做背后的意义与考量是基于什么前提的？这本书从“和甲方沟通的过程”以及“乙方内部代码实现”两层视角考虑敏捷开发的核心在于何处。大有裨益，也许也是常读常新。

推荐给入门的SM和AC看，有一些TW调整后的思路，对自己团队调整的思路有一些启发。 同时里面推荐的书也值得读！

这本书对于我来说可能并不是很大的裨益；书中的一些观点对于目前的开发过程来说有借鉴的意义，但是理论我个人感觉还是有写生硬； 敏捷管理中，团队的沟通协作与传统的开发模式关系更加融洽，大家的相处的方式也更加像伙伴，打破了传统的协作模式； 对于整体的开发流程，敏捷回分为更多的sprint来进行，这些在时代变化迅速的今天，非常具有时代性，能够快速满足产品上线的要求。 敏捷形式纸面上谈起来可能更加方便，但在实践方式上来说可能面临很多挑战，毕竟属于舶来品，在今天的中国互联网时代有些公司并不能深入来应用起来。 以上，通过本书对于敏捷的理解。

这是一本ThoughtWorks多名职员共同撰写关于各自的敏捷故事。读完给我这个身处传统IT行业的我有了一些新的认识，以及提供给我了一些关于团队项目开发敏捷实施的具体可操作的经验。大致总结为如下几点: 1.建立产品项目的看板，可视化的展现出当前项目的进度、任务列表、交付日期以及客户要求等等，把整个项目分解为一个一个的story分别来实现。 2.加强团队沟通协作能力，比如可组织每日开展站会，代码回顾会议，定期开展产品迭代会议，不定期可邀请客户参加的产品展示会，结对编程。站会开展需要坚持以下几个原则:a.时长不超过15分钟，可选择在每日早晨上班时开展；b.一次只由一个人发言；c.讲述的内容前期可参考为昨天做了什么今天准备做什么有什么困难和问题需要团队解决；代码回顾会议开展需要坚持以下几个原则:a.时长控制在一小时左右；b.团队成员轮流展示自己当天编写的一段代码，团队成员看后可谈谈这段代码有什么地方可以学习借鉴之处，然后再谈谈需要改进的地方。 3.引入自动化测试工具，持续集成工具Jenkins，敏捷管理工具Jira，测试驱动开发TDD思想

二零二零年读完的第十五本，也是TW团队写作的第三本书，主要还是分享了实践敏捷的一些方法论及注意事项，我觉得对于想要成为团队领导的同学还是受益的。我发现TW的很多理念我在有意无意中吸收了很多，有时候我都会发现自己比很多TWer都更TW 😄

近年来，关于敏捷的讨论没有那么多了，这可能和越来越多的组织完成了敏捷转型有关。 然而事实上，敏捷组织的延续也是一个值得探讨的问题：新人不断被吸纳进入组织，而在一线，当年敏捷转型的参与者却不断流失，敏捷实践的价值上下文也随之丢失——结果是，在新人看来，这些实践几乎是组织“生来就有”而不容置疑的。 和dev缺失业务上下文的后果一样，敏捷新人也很难理解既有实践的价值。一种可能的结果是他们不理解好实践到底解决了什么问题，导致在执行层面流于形式，动作变形；另一种可能的结果更糟糕，对于坏实践，或者随着环境变化而不再适用的实践，只当是老祖宗留下的不可言说的宝贝，不敢提出质疑，致使每天上班如同参加宗教仪式。 敏捷组织的延续问题任重而道远，迫使我思考这一问题，并向既往案例和典籍寻求答案的，是一次关于估点该不该用“人天法”的辩论。作为敏捷新人，我曾认为在组织内见到的一切都理所应当，忽视了敏捷实践本身也应包容和积极应对变化。实际上，除了对交付价值的追求之外，我们应当随时准备产生新的变化。 于加入ThoughtWorks一周年之际。希望关于敏捷的讨论能够来的更猛烈些。

在飞机上看完了这本书(很诧异，我居然会找这种书来看[吓]，也很诧异，我居然把这书看完了[吓])。我们目前所遇到的问题书中都有提及。诚然每个团队都有适合自己的一套方式，不过，多借鉴成熟的方法体系还是大有裨益的