極限編程XP的關(guān)鍵實踐（二）

首先，我們依然是從這張圖開始。

今天的內(nèi)容，我們將繼續(xù)聚焦小組實踐剩余的三個關(guān)鍵實踐以及交付和管理相關(guān)的內(nèi)容，我們就一個一個的繼續(xù)來看吧。

小組實踐（三）：編碼標準

編碼標準這個東西，看似和編程的相關(guān)性更大，但為什么會劃分到小組的實踐中呢？其實這個東西吧，一說出來大家就明白了。

XP 的目的，就是為了讓小組有一個嚴格和規(guī)范的編碼標準，這樣就能代替文檔，讓代碼成為小組成員間交流的工具。你說，這是不是一個小組工具呢？

我曾經(jīng)待過的一個公司，也不算是特別大的公司，是一個上市公司的子公司。程序員吧，說多不多，說少也不少。我在其中感受最深的就是，我們所有 PHP 工程師寫出來的代碼基本都是一樣的。什么意思呢？如果沒有注釋，如果沒有 Git 記錄，你可能很難分辨出這段代碼是誰寫得。我們在入職的時候，都會熟讀一份編碼標準的文檔，然后統(tǒng)一都按這個文檔來執(zhí)行。并且在 Code Review ，也就是代碼審查的時候，也會在團隊的指引下對不符合規(guī)范的代碼進行修正。

當然，這只是一個實例，好處自然不用多說，各個部分自解釋，溝通確實是不需要文檔，因為他的代碼一拿過來我就知道這一段或者那一段是在干什么的。另外，我隨時可以迅速的維護另一個人之前寫過的內(nèi)容。壞處嘛，也有，那就是這樣的工程會缺少一些靈性，很多東西會寫得過于死板。但是對于大公司或者大型的項目而言，它的好處是要大于壞處的。

從上面的例子以及前人的經(jīng)驗來說，我們可以總結(jié)出編碼標準的七個原則：

• 不要預先花費太多時間

• 目標應該是團隊中沒有人辨認各自的代碼

• 以團隊為單位對某一標準達成協(xié)議，然后遵守這一標準

• 不是事無巨細的規(guī)則列表，而是確保代碼可交流的指導方針

• 編碼標準開始時應很簡單，然后根據(jù)團隊經(jīng)驗逐步進化

• 創(chuàng)建能夠工作的最簡單標準，然后逐步發(fā)展

• 只制訂適合本團隊的

小組實踐（四）：集體擁有代碼

這個概念其實現(xiàn)在在日常的企業(yè)中也開始越來越多的出現(xiàn)了。那就是代碼是“我們”的，而不是“我”的，也就是說，我們都可以修改任何人的代碼，這個代碼也是屬于任何人的，而不是某個特定的人。不過，你改動沒關(guān)系，但請通過我的測試，如果測試有問題，那么提交之后就會影響線上的運行，進而影響整個團隊。從這里來說，又和之前講過的測試驅(qū)動開發(fā)聯(lián)系上了，果然還是一環(huán)套一環(huán)啊。

另外，光是測試還不夠，我們還要有 編碼標準 ，可以 結(jié)對編程 ，能夠進行 簡單設(shè)計 。這一系列相關(guān)的實踐操作能夠在團隊內(nèi)靈活運用的話，才能說我們的代碼可以達到真正的集體所有。

跨敏捷小團隊范圍的代碼也是可以共享的，前提是這些不同的小團隊應該是服務于同一個大的項目。而人數(shù)不多的小范圍集體擁有代碼也是敏捷所推崇的。

小組實踐（五）：穩(wěn)定高速的步伐

這個應該是所有碼農(nóng)都喜歡的，而所有管理者都討厭的一個東西了。為啥呢？穩(wěn)定兩個字透露出來的是什么含義？就是別突然給我加班呀。我們要保持一個穩(wěn)定的速率，在每個迭代周期內(nèi)應該完成差不多的東西，并且讓團隊把注意力集中起來，專注地在工作時間內(nèi)完成更多的東西，這樣就能夠達到高速的目的。

嗯，老外那邊對于加班這個問題確實還是看得比較重的。其實硅谷的大公司加班的不在少數(shù)，但他們確實也把待遇和金錢給到位了。而國內(nèi)的公司，除了少數(shù)頭部大企業(yè)之外，很多小企業(yè)都只是想要培養(yǎng)狼，卻不給狼吃肉的這種尷尬狀態(tài)，也就是我們最常說的 996 ，而且小企業(yè)還是根本沒有任何補貼的 996 。

這個東西吧，不多做討論了。畢竟我還在一個大小周的公司上班，雖說沒有到 996 這個地步，但還是每兩周都多了一天的上班時間。有些東西，年輕的時候經(jīng)歷一下可以，但上了年齡之后，就不要羞于不談條件了，改變不了的話就談條件，該得到的應該要去爭取。

交付和管理（一）：完整的團隊

XP 所期望的完整的團隊是什么樣的呢？不是你想的什么美工、前后端、運維這些人到齊就行了。而是包括上述人員之外，還有客戶、測試、產(chǎn)品、項目等各種角色的人一起。當然，這些人最好還是之前講過的 T 型人才，一門精通，還順便能了解其它的高級人才。

在 XP 中，沒有強調(diào)團隊的人數(shù)，不過依據(jù)敏捷的原則來說，團隊人數(shù)也不宜過多。要想湊齊這樣的一個包含全部人員的團隊其實還是有難度的。如果有條件的話，可以讓客戶、測試、產(chǎn)品這些盡量多參與，并且盡量坐得離我們的團隊更近一些。只要能夠達成有效、快捷的溝通，那么我們的團隊就是一個完整的團隊。這里的完整不限于任何形式。

交付和管理（二）：計劃游戲

計劃就計劃，怎么扯到了游戲上？傳統(tǒng)項目管理最擅長做的是什么？計劃！傳統(tǒng)項目管理最讓人受不了的是什么？計劃！做計劃，本身就是一件說起來容易做起來難的事情。想想你在每年的年初立過多少 Flag ，又有多少能夠做到。

在 XP 中，我們將計劃稱為計劃游戲。用游戲這兩個字其實是想讓 計劃 這個東西變得輕松一些。因為傳統(tǒng)的項目管理中，特別是在 PMP 中，你會發(fā)現(xiàn)大部分的東西都是在 規(guī)劃過程組 中做的，最后形成的那個 項目管理計劃 更是一幅 鴻篇巨制 。但結(jié)果呢？大部分的項目最后的結(jié)果都不一定甚至很大程度上會偏離那個寫了很久的 項目管理計劃 。

而 XP 中的計劃，是通過不同的階段進行的，并且是貫穿整個項目開發(fā)過程始終的。

在探測階段，客戶和開發(fā)人員會產(chǎn)生評估和用戶故事。

在計劃階段，客戶和開發(fā)人員一起制訂、發(fā)布計劃（包含每一次的發(fā)布計劃、每一次的迭代計劃）。

在調(diào)整階段，客戶和開發(fā)人員一起針對開發(fā)過程中的實際情況，對計劃不停的調(diào)整甚至制訂新的計劃。

這就是 XP 中的計劃游戲，千萬別被 游戲 這兩個字誤導，它和游戲還真沒什么關(guān)系，只是一種制定計劃的方式。我們在 Scrum 中也會看到 Scrum 是如何來制定計劃的，跟 XP 的還真不太一樣。

交付和管理（三）：現(xiàn)場團隊

在現(xiàn)場團隊這個概念中，客戶是非常重要的。通常來說，客戶是很難跟我們天天在一起工作的。這時候，可以選擇一個 用戶代表 來代替客戶的職責。如果有不清楚的地方，他能隨時和客戶方進行快速地溝通。通常來說，讓團隊中的產(chǎn)品負責人來擔任這個角色會比較好。

交付和管理（四）：小規(guī)模發(fā)布

小規(guī)模發(fā)布的另一層含義就是能夠頻繁地發(fā)布。有多頻繁呢？最佳選擇就是每一次的持續(xù)構(gòu)建之后，馬上就進行發(fā)布。當然，這也要視我們開發(fā)的情況而定，大部分情況下，我們的一次迭代所能交付的，應該就是可以上線正式運行的功能。但是，一些大型的功能可能需要受制于其它功能的迭代開發(fā)完成才能一起上線，這時，就需要再等一兩個迭代。當然，也可以制定對應的發(fā)布計劃，比如幾個迭代之后會有一次全量發(fā)布，而每次迭代都是一次增量發(fā)布等。

對于小規(guī)模的發(fā)布來說，可以降低項目開發(fā)過程中的風險，也能夠快速獲得用戶的反饋并且及時響應，這同時也促進了開發(fā)團隊與客戶之間的交流。不過要實現(xiàn)小規(guī)模發(fā)布，也需要在有測試驅(qū)動開發(fā)、持續(xù)集成、代碼重構(gòu)以及優(yōu)良的編碼規(guī)范的前提條件下，才能讓小規(guī)模發(fā)布能夠有條不紊地執(zhí)行。

總結(jié)

怎么樣，XP 的實踐是不是讓你怦然心動。不過還是那句話，這些實踐有的很容易實現(xiàn)，有的卻很難，具體怎么取舍，還是要看你所在的組織情況以及領(lǐng)導的支持態(tài)度。而更多的情況是，這些實踐已經(jīng)不單單是 XP 中所獨有的，也不是一定要完全遵守的。由此帶來的就是，很多實踐我們會在不怎么執(zhí)行敏捷的企業(yè)中看到，而有實踐則可能在貫徹敏捷的團隊中卻無法發(fā)現(xiàn)。

參考文檔：

《某培訓機構(gòu)教材》

《用戶故事與敏捷方法》

《高效通過PMI-ACP考試（第2版）》

《敏捷項目管理與PMI-ACP應試指南》