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

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

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

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

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

一. 不容易做到的實踐

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

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

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

二. 容易做到的實踐

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

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

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

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

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

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

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

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

”試驗方案“，做之前先試試行不行，這個是好主意，開發(fā)和領(lǐng)導(dǎo)一般都會喜歡。

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

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

三. 靈活做到的實踐

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

四. 需要做到的實踐

關(guān)于實踐，這部分才是重點，即那些沒有那么容易做到但是需要我們?nèi)プ龅降膶嵺`。

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

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

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

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

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

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

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

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

五. 小結(jié)

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

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。