ThoughtWorks敏捷開發(fā)管理體系

做了多年的組織轉(zhuǎn)型咨詢，如果約束到軟件開發(fā)領(lǐng)域，管理體系（暫且認為文化部分屬于領(lǐng)導(dǎo)力）基本就是以下四個方面。

• 需求管理：包含從需求澄清到需求最終實現(xiàn)的整個生命周期。
• 技術(shù)管理：包含開發(fā)、測試技術(shù)的選擇和運用。
• 質(zhì)量管理：包含開發(fā)過程中的質(zhì)量管理及軟件交付前的質(zhì)量保障。
• 迭代管理：包含開發(fā)團隊迭代運作規(guī)則及紀律。

顯然ThoughtWorks敏捷開發(fā)需求管理是圍繞Story展開，其核心是能夠支持小批量、小批次的精益模式，同時還要能夠盡量保證每個Story業(yè)務(wù)價值明確。《敏捷軟件開發(fā)：用戶故事實戰(zhàn)》這本書可能是ThoughtWorks內(nèi)部沒有任何負面評價的實踐級著作了。近十年時間里，大家頗有微詞的地方可能是書中對故事大小評估的描述，但INVEST原則的抽象可為神來之筆。

Story作為需求的管理方法，所有的技術(shù)、質(zhì)量和迭代管理其實都是圍繞這個中心，畢竟最后開發(fā)目的是實現(xiàn)價值，而Story承載著業(yè)務(wù)價值。順便提一句，Story的質(zhì)量其實是一個核心問題，ThoughtWorks從來不提倡一句話Story描述，即僅僅表面上遵循了As…I want…So that的經(jīng)典模式，驗收條件對于一個Story來說至關(guān)重要。

值得一提的是圍繞Story的可視化系統(tǒng)，每個團隊都會有一面類似下圖的迭代看板，看板上流動的是迭代內(nèi)的Story，而Story的生命周期則通過順序的泳道展現(xiàn)給團隊所有人。

技術(shù)和質(zhì)量管理的核心仍然是前文提到的質(zhì)量內(nèi)建。持續(xù)集成和自動化測試實際上都將質(zhì)量管理融入到了技術(shù)工程體系里。在ThoughtWorks敏捷開發(fā)體系里，很難將技術(shù)管理和質(zhì)量管理分開，重過程質(zhì)量是這個管理體系的精髓，由此也在2012年演進為“持續(xù)交付”的概念。

由于是全功能團隊，并工作在統(tǒng)一節(jié)奏下，所以迭代管理的范圍中，除了類似Scrum四會協(xié)作儀式機制，其余硬性紀律較少。為了保證（成果和問題）“集體所有”（Collective Ownership），ThoughtWorks敏捷開發(fā)實踐方面特別注意不會聚焦到個體，比如我們說到的Story估點和Velocity統(tǒng)計都是團隊為單位，不會指定或統(tǒng)計到個人。

迭代過程中的缺陷也不會追溯到某個特定開發(fā)人員。唯一產(chǎn)生個體比較和競爭的可能是在技術(shù)卓越原則下的比拼，比如作為TL，至少你寫出的代碼應(yīng)該是讓團隊其他成員賞心悅目。

雖然這里不談文化，但還是必須強調(diào)這樣的管理模式本質(zhì)上是將“價值驅(qū)動、技術(shù)卓越”上升到文化價值觀層面作為支撐才得以實現(xiàn)的。即便經(jīng)常拿尚奇口中的tech@core開玩笑，但實質(zhì)上這是ThoughtWorks敏捷開發(fā)模式能夠工作的重要底座。也是為什么很多其他團隊感覺ThoughtWorks這種管理模式不可行的核心癥結(jié)。

行文至此，問一句，這些與你感受和認知的ThoughtWorks敏捷開發(fā)差異大嗎？-：）

關(guān)于本書的其他說明

其一是我們的行文風格。在某些地方，我們使用了中英文混雜的描述，這個可能會被如前所述，本書取材于與ThoughtWorks諸多同事多年以來的實踐，因而在描述過程中，基本上也體現(xiàn)了實際場景下的交流，這種表述在有些情況下可能被外行人疑似為散裝英語，但如果你身處快節(jié)奏的互聯(lián)網(wǎng)開發(fā)環(huán)境，就會明白溝通的真正含義是“講的話彼此都能聽懂，從而達成共識，迅速采取有效的行動”，而不是為了單純追求規(guī)范而陷入“邯鄲學(xué)步”的尷尬境地。

其二是文中提及一些參考的文章，因為紙版印刷的限制，考慮到超鏈接可能引發(fā)的閱讀不適，所以未作保留，有興趣的讀者可以自行從網(wǎng)絡(luò)或者ThoughtWorks洞見網(wǎng)站（https://insights.thoughtworks.cn）搜到對應(yīng)的內(nèi)容。

最后，讓我們互通有無，期待大家的反饋！

---

（1）　請訪問ThoughtWorks洞見公眾號同名文章。