上一篇文章中說到的敏捷宣言，可以說是整個(gè)敏捷體系中最精髓的部分了。說實(shí)話，不僅你覺得，我也覺得這四句話有點(diǎn)太簡單，太抽象了。難道真正的敏捷只是遵循這四句話就可以了嗎？不要 too young too simple 了。
在現(xiàn)實(shí)的項(xiàng)目環(huán)境中，各種因素往往是復(fù)雜多變的，敏捷宣言的概括雖說是可以覆蓋到大部分的問題，但畢竟還是太過于籠統(tǒng)抽象了。所以，各位大佬們在發(fā)布敏捷宣言的同時(shí)，還給出了 12 條敏捷原則，可以看成是對敏捷宣言的官方解釋及補(bǔ)充。
既然這么說了，那么其實(shí)也就意味著這 12 條敏捷原則也是官方給出的東西了唄。因此，不管是考試還是面試，這 12 條原則就和敏捷宣言一樣，是必須掌握的東西。幸好的是，這 12 條原則也非常地“簡單”。
有印象嗎？對應(yīng)的是敏捷宣言中的哪句話呢？這個(gè)原則可是照搬過來的哦！
在這一個(gè)原則，我們就會(huì)看到幾個(gè)名詞：持續(xù)交付、客戶價(jià)值，以及為了實(shí)現(xiàn)這個(gè)原則所應(yīng)該采取的開發(fā)方式：迭代式生命周期。記住，這些名詞都和這個(gè)原則有著千絲萬縷的關(guān)系。
同樣的，這個(gè)原則也是來自于敏捷宣言中的一句話。另外，這里有客戶價(jià)值和迭代思想的體現(xiàn)，通過快速迭代來實(shí)現(xiàn)客戶的競爭優(yōu)勢從而提高客戶價(jià)值。
這個(gè)原則也是與傳統(tǒng)的項(xiàng)目管理最不同的一點(diǎn)，傳統(tǒng)的項(xiàng)目管理中，非常注重的一點(diǎn)就是變化是一切罪惡的根源。所有的一切應(yīng)該是圍繞著計(jì)劃進(jìn)行的，變化會(huì)產(chǎn)生一系列的問題，包括但不限于時(shí)間延長、成本增加、質(zhì)量降低等等。所有的變化一定要走完善的變更流程，要有記錄，要能追溯。但是，在敏捷中，變化是受歡迎的，是值得我們?nèi)肀У?，為什么呢？就是上面的原因，它能夠提升客戶價(jià)值。
這個(gè)原則是順著原則二的繼續(xù)深入。快速地、短期的交付，也就是讓客戶和用戶在很短的時(shí)間間隔里就可以體驗(yàn)到新的、不斷累加的產(chǎn)品功能，就能盡早地讓客戶驗(yàn)證對產(chǎn)品的想法以及盡早地發(fā)現(xiàn)產(chǎn)品中的問題。
通常來說，在 Scrum 中，迭代（沖刺）周期一般為 2 到 4 周。而在 XP 中，則更有可能一周就完成一次迭代。
這個(gè)原則很明顯是在說明溝通的重要性。在現(xiàn)代社會(huì)中，我們很多人即使天天坐在一個(gè)辦公室里，也只會(huì)通過 QQ 、微信之類的聊天工具來交流。而在敏捷中，更提倡的是面對面的溝通，而且在項(xiàng)目成員和客戶之間，最好也是沒有隔閡的就在一個(gè)地方辦公，而且有什么問題都是直接能夠用面對面的說話來交流的。
當(dāng)然，這真的非常難。在傳統(tǒng)的項(xiàng)目開發(fā)中，外包團(tuán)隊(duì)經(jīng)常會(huì)有入駐的開發(fā)形式，其實(shí)這就是為了更好的解決溝通問題。但是，在敏捷中，更提倡的是讓客戶也就是甲方派一些關(guān)鍵人物參與到乙方的工作中來。這樣就能夠快速的獲得客戶的意見，同時(shí)客戶也能夠隨時(shí)清晰地知道開發(fā)的狀態(tài)。
在這其中，除了在一起工作之外，看板是也一個(gè)協(xié)同辦公很重要的工具，還包括站會(huì)、回顧會(huì)議等等各種簡單小型的會(huì)議。如果不能在一起工作的話，或者不能面對面的工作溝通的話，這些溝通工具就完全不能發(fā)揮它們的作用。
就和前面說過的一樣，讓雙方甚至多方天天在一起工作真的很難。但總有一些方法可以解決，比如周期性地同步工作一段時(shí)間，或者由資深的業(yè)務(wù)分析師來充當(dāng)“用戶代言人”。
在敏捷中，人是整個(gè)項(xiàng)目成功非常重要的一個(gè)因素。而在傳統(tǒng)的項(xiàng)目管理中，人則是一個(gè)工具。也就是說，在傳統(tǒng)項(xiàng)目管理中，所有的人都要遵循計(jì)劃，告訴他應(yīng)該做什么，怎么做。而在敏捷中，則是以激勵(lì)為主，不會(huì)告訴你做什么，一切以你自己來決定。通過用戶故事來認(rèn)領(lǐng)你要完成的工作，通過故事點(diǎn)數(shù)來評估自己完成的速率。團(tuán)隊(duì)里的人都會(huì)認(rèn)可你的工作，也會(huì)無條件的支持你、信任你。
在這里，我們會(huì)聯(lián)想到幾個(gè)名詞：自組織、團(tuán)隊(duì)、勇氣以及尊重。在將來的學(xué)習(xí)中，我們還會(huì)見到它們的身影。
不用多解釋了吧？和原則四的內(nèi)容很貼切吧，在原則四中我們也講過了，面對面的交流溝通是敏捷中最重要的內(nèi)容。
在人和人的交流中，面對面溝通時(shí)三大要素影響力的比率是：文字7%，聲音38%，肢體動(dòng)作55%。因此，為什么原則四要強(qiáng)調(diào)在一起辦公的原因也再明顯不過了。當(dāng)然，我們也可以排個(gè)序，面對面說話當(dāng)然是最好的，其次是視頻會(huì)議，再次是電話會(huì)議，而文檔的傳遞也就是傳統(tǒng)意義上的郵件溝通則是最差的一種交流方式。
當(dāng)然，我們并不是說禁止一切的文檔交流。在某些情況下，一些 Wiki 類文檔有其獨(dú)特的功用，而且是不可代替的功用。
這里又再次提到了工作的軟件，也就是正式可用的軟件。既然我們不停地迭代，不停地上線。那么如果客戶想要知道現(xiàn)在的進(jìn)度，直接使用線上的軟件就可以了呀。要知道，敏捷區(qū)別于傳統(tǒng)項(xiàng)目開發(fā)的一大特點(diǎn)就是不停地持續(xù)交付真正可用的軟件產(chǎn)品。
在敏捷中，一個(gè)功能無法使用，也就意味著這個(gè)功能是沒有交付的。這種情況下，進(jìn)度標(biāo)準(zhǔn)就被清晰的定義為每個(gè)功能是否交付，而且只有兩個(gè)選項(xiàng)，已交付和未交付。當(dāng)然，對于開發(fā)團(tuán)隊(duì)來說可能還有更多的選項(xiàng)，但對于客戶來說，這兩個(gè)就足夠讓他們清晰的知道現(xiàn)在產(chǎn)品已經(jīng)開發(fā)到什么狀態(tài)了。
其實(shí)說人話就是每次迭代的時(shí)間保持一致。比如我們確定好了兩周一個(gè)迭代，那么后面就盡量不要改變這個(gè)迭代周期。另外一點(diǎn)則是每次迭代所完成的工作量也應(yīng)該是要保持一致的。在這里，我們會(huì)用到“用戶故事”中的“故事點(diǎn)”的概念。也就是每次迭代我們都應(yīng)該完成相同的“故事點(diǎn)”功能以實(shí)現(xiàn)迭代中工作量的一致性。
良好的迭代規(guī)律能夠?yàn)閳F(tuán)隊(duì)帶來歡樂和生產(chǎn)力。試想在一個(gè)動(dòng)蕩的，充滿不確定性的環(huán)境中，如何才能讓團(tuán)隊(duì)保持平衡產(chǎn)出呢？另外，也可以將一次項(xiàng)目的開發(fā)比喻成一次長跑，在奧運(yùn)會(huì)的長跑比賽中，解說員都會(huì)說穩(wěn)定的節(jié)奏對于長跑的重要性。而短跑更像是每一次的迭代，在 Scrum 中，迭代也叫做沖刺。因此，整個(gè)項(xiàng)目開發(fā)過程，其實(shí)就是在穩(wěn)定節(jié)奏下的一次次拼盡全力的沖刺。
這一點(diǎn)可以說是更重視于軟件開發(fā)中的架構(gòu)設(shè)計(jì)。代碼一旦變得復(fù)雜，冗余，就會(huì)失去敏捷性。特別是長時(shí)間積累的，經(jīng)過多人之手的傳說中的“shi山”級別代碼。之所以說不斷關(guān)注，原因其實(shí)就像我們的項(xiàng)目進(jìn)程一樣，對于代碼來說，也是不斷地迭代升級的，當(dāng)然，它有一個(gè)更專業(yè)的名詞：“重構(gòu)”。
持續(xù)不斷的重構(gòu)，其實(shí)也正對應(yīng)著敏捷中的一個(gè)思想，那就是不斷精進(jìn)，這個(gè)概念來源于豐田的精益生產(chǎn)標(biāo)準(zhǔn)。而這個(gè)精益生產(chǎn)，也正是敏捷思想的啟蒙概念之一。把控每一個(gè)環(huán)節(jié)，消除浪費(fèi)，對應(yīng)到敏捷軟件開發(fā)的實(shí)踐中，就是測試先行、持續(xù)集成以及重構(gòu)的綜合應(yīng)用。要知道，返工和嚴(yán)重的 BUG ，正是最大的浪費(fèi)來源。
這個(gè)原則是我最喜歡的原則，當(dāng)然，相信也是不少人最喜歡的原則。敏捷從不提倡過度設(shè)計(jì)，所以，適合當(dāng)下的就是最好的。即使要為將來做準(zhǔn)備，也要在嚴(yán)謹(jǐn)?shù)恼撟C基礎(chǔ)上進(jìn)行適當(dāng)?shù)臄U(kuò)展準(zhǔn)備。
反過來說，這個(gè)原則最主要杜絕的其實(shí)也是一種浪費(fèi)，那就是過度設(shè)計(jì)的浪費(fèi)。我們經(jīng)歷過太多的項(xiàng)目，真的是看別人有什么就要做什么，最后的結(jié)果卻總是不了了之了。根據(jù)28法則（帕累托），你的項(xiàng)目中用戶最常用的功能其實(shí)只有那么 20% ，而剩下的 80% 可能大部分人都根本不知道。當(dāng)然，也就可能剩下的這 80% 功能是為了那 20% 的用戶所準(zhǔn)備的。不過，如果是一個(gè)迭代的敏捷開發(fā)過程，那么我們最優(yōu)先要做的，正是那 20% 的核心功能。至于如何做呢？最簡單的方式去實(shí)現(xiàn)他們。然后在將來不斷地重構(gòu)升級。
敏捷很重視個(gè)人，但其實(shí)它更在乎的是整個(gè)團(tuán)隊(duì)。而在各種團(tuán)隊(duì)形式中，敏捷又最推崇的是自組織的團(tuán)隊(duì)。這是一種什么樣的團(tuán)隊(duì)呢？代碼共有、人人負(fù)責(zé)、團(tuán)隊(duì)計(jì)劃、自主分解、自主協(xié)作、自我約定?？粗遣皇歉杏X很美好，沒錯(cuò)，這樣的團(tuán)隊(duì)非常難形成。
首先，我們要有一個(gè)小而精的規(guī)模，敏捷中不提倡太大的團(tuán)隊(duì)，如果人數(shù)過多，那么混亂也就隨之而來。團(tuán)隊(duì)也一樣要“簡單”。
其次，團(tuán)隊(duì)成員的水平要高，甚至最好是通才。但這個(gè)太難實(shí)現(xiàn)了，所以，我們推崇教練機(jī)制。說白了，就是一種老帶新的機(jī)制，有項(xiàng)目管理教練，有編碼教練，當(dāng)然也可以有產(chǎn)品教練，設(shè)計(jì)教練。
最后，團(tuán)隊(duì)宗旨要明確，沒有目標(biāo)的團(tuán)隊(duì)很難取得進(jìn)步，在團(tuán)隊(duì)內(nèi)部也很難溝通，至少，我們要為了同一個(gè)目的去工作，不是嗎？
這個(gè)原則好理解，我們中國有句古話“吾日三省吾身”。這句話出自《論語》，意思就是每天都要對自己提三個(gè)問題進(jìn)行反思。而在敏捷中，我們也非常重視這個(gè)反省的過程。因?yàn)槲覀兊牡俣瓤?，所以有時(shí)候一些錯(cuò)誤的構(gòu)架和 BUG 確實(shí)是不可避免的，但是要拿出“勇氣”，敢于“反省”和“重構(gòu)”。另外最重要的一點(diǎn)是，這些都是在團(tuán)隊(duì)的基礎(chǔ)上進(jìn)行的，也就是說，錯(cuò)誤不是某一個(gè)人的，而是團(tuán)隊(duì)中的問題。
在 Scrum 中，回顧會(huì)議就是非常重要的一個(gè)會(huì)議。通常在一個(gè)迭代結(jié)束之后都要進(jìn)行一次回顧會(huì)議。目的就是讓團(tuán)隊(duì)搞清楚我們在上一個(gè)迭代做了什么，有哪些收獲，有哪些不足，怎么改進(jìn)。說實(shí)話，不管是團(tuán)隊(duì)還是個(gè)人的進(jìn)步，真像都在于我們?nèi)绾稳タ偨Y(jié)沉淀自己的經(jīng)驗(yàn)。
內(nèi)容有點(diǎn)多吧？沒辦法，畢竟十二條原則，說多不多，說少不少的。就像開頭所說的，如果是有特殊的目的來進(jìn)行學(xué)習(xí)的話，那這十二條原則是必須要背的內(nèi)容。
通過這十二條原則以及一些相應(yīng)的解釋，相信大家看到了不少很熟悉但又陌生的名詞。別急，在后面的學(xué)習(xí)中我們還會(huì)見到并且學(xué)習(xí)到它們。
參考文檔：
《某培訓(xùn)機(jī)構(gòu)教材》
《用戶故事與敏捷方法》
《高效通過PMI-ACP考試（第2版）》
《敏捷項(xiàng)目管理與PMI-ACP應(yīng)試指南》
