本人是學院派，總認為理論能夠指導實踐，所以平時對研發管理方面的書看得比較多。最近在別人影響下開始寫博客，回想以前看過的很多好書，覺得可以拿出來和大家做一下分享。

3、4年前開始接觸敏捷思想，12年的時候去拿了CSM證書，當然考試本身不值一提，我也不認為敏捷能解決所有問題，但是敏捷的思想確實對后續的工作產生了很大影響，有幾本敏捷相關的書籍可以幫忙我們更好的去理解和把握如何在開發過程中應用或者至少借鑒其中的精華。今天要分享的這本書《The Art of Agile Development》，個人認為是其中的代表，也稱得上是XP領域目前最好的一本書。

《The Art of Agile Development》的第一作者James Shore也是敏捷領域的大師級人物，而且兩位作者的文筆功底還是很不錯的，整本書下來思路、用詞、章節安排以及行文可以說行云流水，中文版翻譯也是可圈可點。

全書的第一部分從敏捷的基本理念入手，重點講解XP這一特定敏捷模型的各個方面并對團隊是否適合XP進行了深入剖析，從而引出來第二部分中的各項實踐。本文的重點就是通過理解書中的這些實踐分析現實研發過程中的問題并試圖找出解決這些問題的方法。第三部分應該說脫離了XP而把主題上升到整個敏捷的價值觀和過程改進的方法論上，同時又一定程度上結合了精益思想號召我們要消除浪費并以價值的交付為做行動導向。

縱觀Scrum和XP這兩個敏捷領域最廣為采用的模型，有很多共通點，這些共通點主要體現還是在具體做法上，而不是方法論上。如果用一句話來概括兩者之間的區別，就是：XP偏向工程實踐，而Scrum側重流程管理。這一點在這本書中也是體現的很明顯，作者還是想把具體各個實踐講得更加清楚明白，而不是嘗試把他們整合起來以形成一個工作流程。全書有約四分之三的篇幅在講解思考、協作、發布、計劃和開發這五大類共計37個工程實踐，下面我們就從這些工程實踐中看看能否和實際研發過程結合起來，做到文章開頭提到的理論指導實踐。

一. 不容易做到的實踐

首先，個人認為在國內很多實踐可以嘗試做，但要做到像國外那么徹底、那么直接是不現實的，典型代表就是書中的第一個實踐“結對編程”。敏捷領域里，大家都說結對編程是個好東西，我們可能也模模糊糊覺得應該也不錯，但要做起來我覺得太難，無論環境、資源和管理理念上都顯得格格不入，至少本人從來不會說大家來結對編程一把，可能更多是要建立Mentor機制，老師傅手把手來教新人，很多時間這種教法也是兩個人一起寫點代碼或做些設計，這可能算是“結對”這種思想的變種吧。

另一個不大容易做到的實踐是TDD，個人完全認為TDD是個好東西，自己也曾經嘗試通過TDD來寫點代碼，但寫起來實在有點累。TDD對個人素質要求之高是很明顯的，做起來不會像一些書上舉得例子那樣順利。國內很多公司，包括我現在的這家，面對項目線、產品線的要求，能夠做到核心業務層代碼都能覆蓋單元測試已經是很好了，如果團隊整體水平沒有達到很高的層次，使用TDD可能只會降低開發效率。

敏捷領域有幾句話很直接，例如“如果你的XXX條件沒有滿足，你就不是在實行敏捷”，所以有時候我覺得如果我們不做“結對編程”和"TDD"，我們還能說我們是在嘗試敏捷嗎？可能就不一定是了，所以類如這本書中“沒有bug”這樣的實踐也就變得好像有點遙不可及了。

二. 容易做到的實踐

幸好這本書里有些實踐我們還是比較容易做到的：

“精力充沛的工作”，貌似大家還是比較有精神的，中午小憩一下，下午的效率也應該不錯。

“信息化工作場地”，就算現在沒有，跟老板說一聲，要想有一般也不是什么難事情，關鍵是怎么樣設計信息化的表現形式。

“坐在一起“，通常比較簡單，但實施型項目經理表示我可是要出差的哦。

”站立會議“，更普遍的是它的英文叫法Stand-up Meeting，也是Scrum流程中的一環，現在很多公司都在做，我們每天都做。

“版本控制”，書里特指代碼而不是廣義上的的版本控制，那就比較簡單了，什么SVN、Git我們都是可以用的。

”十分鐘構建"，書里講的是原理，實踐過程中我們用的是工具，對于不是太大的系統，10分鐘的構建時間足夠了。

”重構“，我覺得只要有思路，重構還是有很多模式和套路可以直接拿來用的，一般也不會太難，真的很難估計也就不去重構了。

”試驗方案“，做之前先試試行不行，這個是好主意，開發和領導一般都會喜歡。

”代碼集體所有制“，這塊我覺得就是要做好開發人員的backup，真正說所有人都能知道系統是怎么樣的，一上去就能改別人的代碼我覺得也是不對的。確立模塊化思想，讓開發人員能夠主要負責某些模塊、參與協作某些模塊也是這種思想的一種比較實際的表現形式。

”文檔“，敏捷要不要文檔，我覺得是要的，而且要的可能還不少。我們不需要淹沒在像CMMI這樣的文山會海中，但產品線、項目線、研發線該有的文檔還是要有的，不然溝通本身就會成為問題，更不要說有效的團隊協作了。

三. 靈活做到的實踐

書中有些內容已經超越了存粹工程實踐的范疇，例如”信任“；有些實踐也是因人而異，和個人習慣有很大關系，例如”松弛“；有些實踐可能不需要整個研發團隊參與，如“愿景”；類如”真實客戶參與“確實非常之重要，但不是每個項目都會有客戶和你一起來做事情的，客戶或者干系人管理更多的是項目管理過程上應該考慮的問題而不是研發過程，“風險管理”也是屬于這類實踐。這些實踐通常需要視項目和團隊情況靈活進行應用，類似的還有“迭代演示”、“探索性測試”、“增量設計和架構”等。

四. 需要做到的實踐

關于實踐，這部分才是重點，即那些沒有那么容易做到但是需要我們去做到的實踐。

”根源分析“和”回顧“：把這兩個實踐放在一起是因為應用的時候它們往往是一套組合拳，回顧的一大主題就是通過根源分析找到改進方案。回顧在Scrum中是迭代過程結束時的一個固定步驟，這本書中的定位也是如此。書中提到的最高指示、頭腦風暴、靜音貼圖等步驟也都是敏捷回顧領域比較普遍的做法，總體也是參考了Norman Kerth的《Project Retrospectives: A Handbook for Team Reviews》中的一些內容。個人認為回顧非常之重要，后續會有專文講關于回顧的一些總結和體會。而根源分析是過程改進的一種手段，書中講的比較簡單，實際操作上可以具體展開。5個why、魚骨圖等都是常用的分析方法，但真正要能找到根源，沒有量化的數據和統計分析是不行的，這可能也是CMMI中把它定為一個5級過程域的原因吧。個人在團隊中會時常使用回顧和根源進行過程改進。

”統一協作語言“：這一實踐與溝通管理有直接關系，通常研發、產品和項目線會有自己的一些特定溝通風格，如果不做事先引導，大家做在一起開會的時候會明顯感覺到這一點。關于大家怎么樣講同一種語言，作者的基本思路是關注領域而非技術，深表贊同。個人認為要做到統一協作語言，一方面要面向領域，另一方面過程資產的建設也是基礎，常用的領域知識需要按照產品、模塊、功能線、功能點等進行組織并形成文檔，確保大家的認識在同一水平線上。

“編碼規范”：貌似所有開發團隊或多或少都會有稱之為“編碼規范”的東西，我們也有，但個人覺得做的不夠好。書中提到從開發實踐、工具、構建約定等方面制定最小標準合集，并關注一致性。關于如何遵循規范，團隊的過程資產建設是第一步，個人覺得各種同級評審（Peer Review）等沒有在這本書中提到的實踐也是必須要執行的。

“持續集成”：關于持續集成的問題，個人覺得歸根結底還是團隊協作的問題。搭個類似Jenkins這樣的服務器大家上去構建幾把是簡單的，但如果涉及到多人一起代碼提交，如何把握代碼提交的時機、如果確保你提交的代碼不會破壞構建等問題需要團隊對代碼開發的分工等有明確的約定，對提交者個人能力也是一種考驗。至于書中提到的多步集成構建、頻繁構建等是另一個層面可以考慮的問題。

“發布計劃”和“迭代計劃”：在發布計劃這個實踐中，作者提到了幾個重要概念和理念：一次一項目（理想狀態）、盡早發布盡快發布（往往不是研發團隊能夠單方面決定）、縱向條紋（vertical stripes，實際就是面向功能而不是面向任務）、最后責任時刻計劃（精益用語，類似計劃的演進過程），計劃的兩種類型（范圍限定和時間限定）。這里特別強調一下“縱向條紋”，或者有些地方叫做“曳光彈”，這是研發管理中需要管理的接口，即面向發布的應該是功能，而面向研發人員的是任務，通常功能和任務需要進行映射管理。另外，如果我們希望能夠頻繁發布，則我理解我們需要控制發布單元的粒度；至于如何制定發布計劃，敏捷領域一般都是推崇時間限定的發布。有了固定的時間限定，迭代計劃也就提上日程，迭代計劃中通常會使用Task Board進行迭代跟蹤，并需要處理好敏捷里面一個重要概念：DoD。

“故事”和“估算”：如何做估算或者說評估工作量恐怕是軟件行業一個永恒的話題，事情要做到量化確實是很不容易。估算的前提是要進行開發范圍的分解，通常可以從需求->模塊->功能線->功能點->活動這樣的大致思路進行拆分，至于拆分出來的中間產物可以有多種表現形式，故事只是敏捷領域的一種叫法。書中提到了使用理想工程天數、速度、故事卡片等工具和媒介進行估算以達成團隊的統一認識，但個人覺得實際實踐過程中可能會面臨這樣或那樣的問題和挑戰。

“客戶測試”：書中提到了自動化驗收測試的理念，雖然很多時間我們做不到這一點，但客戶參與測試這一步驟通常是必須要有的，不管其手段和表現方式是什么。客戶測試是管理客戶期望，確保項目順利驗收的重要方面，通常在系統試運行階段會有正式的流程，但階段性獲取客戶反饋也有助于把握開發的方向。

“簡單設計”：關于簡單設計書中強調的還是代碼修改和維護的易操作性，諸如避免猜測性代碼、避免重復代碼、自解釋的代碼、隔離組件和限制公開接口、以及使用斷言進行快速失敗等都是設計領域當下普遍的準則和做法，因為這本書差不多是在10年前寫的，相信很多理念在當時應該還是算是比較新穎的。

五. 小結

《The Art of Agile Development》為我們揭開了敏捷的一層面紗，即如何通過XP中的工程實踐進行產品研發和交付。正如大家知道的那樣，敏捷通常只適用于小團隊，而這本書也沒有從團隊協作的角度做深入的探討。如果你沒有研發管理方面的實踐經驗，可能看了之后會發現講得是挺好但不大容易找到在團隊中應用的入手點。

另一方面，敏捷對團隊以及團隊中的成員要求實在太高，既要會思考，又要懂協作，計劃發布都參與，還要代碼寫得好、設計也精通，現實中這種人實在太少，個人入行尚淺，周圍確實沒看到過幾個這樣的人。

當你的團隊人員規模逐步變大，可能需要考慮的問題是團隊成員之間的有效溝通和協作，這種有效的溝通和協作通常已經很難通過面對面交流來實現，而必須要有相對完備的文檔和過程資產，這時候敏捷尤其是XP中的部分工程實踐是可以也是應該作為一種過程集成化的手段嵌入到團隊運作中去，例如把大團隊分組成小團隊，大團隊有自己完整的工作流程，而在小團隊內部可以實行“坐在一起”、“站立會議”等實踐，這種敏捷實踐的嵌入式推行方式相對是比較容易的，效果也是不錯的。

總結

以上是生活随笔為你收集整理的读敏捷系列之《The Art of Agile Development》的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。