深入核心的敏捷開發：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一週年之際。希望關於敏捷的討論能夠來的更猛烈些。

在飛機上看完了這本書(很詫異，我居然會找這種書來看[嚇]，也很詫異，我居然把這書看完了[嚇])。我們目前所遇到的問題書中都有提及。誠然每個團隊都有適合自己的一套方式，不過，多借鑑成熟的方法體系還是大有裨益的