上一篇文章中說到的敏捷宣言，可以說是整個敏捷體系中最精髓的部分了。說實話，不僅你覺得，我也覺得這四句話有點太簡單，太抽象了。難道真正的敏捷只是遵循這四句話就可以了嗎？不要 too young too simple 了。

在現實的專案環境中，各種因素往往是複雜多變的，敏捷宣言的概括雖說是可以覆蓋到大部分的問題，但畢竟還是太過於籠統抽象了。所以，各位大佬們在釋出敏捷宣言的同時，還給出了 12 條敏捷原則，可以看成是對敏捷宣言的官方解釋及補充。

既然這麼說了，那麼其實也就意味著這 12 條敏捷原則也是官方給出的東西了唄。因此，不管是考試還是面試，這 12 條原則就和敏捷宣言一樣，是必須掌握的東西。幸好的是，這 12 條原則也非常地“簡單”。

原則一：我們最優先要做的是通過儘早的、持續的交付有價值的軟體來使客戶滿意

有印象嗎？對應的是敏捷宣言中的哪句話呢？這個原則可是照搬過來的哦！

在這一個原則，我們就會看到幾個名詞：持續交付、客戶價值，以及為了實現這個原則所應該採取的開發方式：迭代式生命週期。記住，這些名詞都和這個原則有著千絲萬縷的關係。

原則二：即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢

同樣的，這個原則也是來自於敏捷宣言中的一句話。另外，這裡有客戶價值和迭代思想的體現，通過快速迭代來實現客戶的競爭優勢從而提高客戶價值。

這個原則也是與傳統的專案管理最不同的一點，傳統的專案管理中，非常注重的一點就是變化是一切罪惡的根源。所有的一切應該是圍繞著計劃進行的，變化會產生一系列的問題，包括但不限於時間延長、成本增加、質量降低等等。所有的變化一定要走完善的變更流程，要有記錄，要能追溯。但是，在敏捷中，變化是受歡迎的，是值得我們去擁抱的，為什麼呢？就是上面的原因，它能夠提升客戶價值。

原則三：經常性地交付可工作的軟體，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好

這個原則是順著原則二的繼續深入。快速地、短期的交付，也就是讓客戶和使用者在很短的時間間隔裡就可以體驗到新的、不斷累加的產品功能，就能儘早地讓客戶驗證對產品的想法以及儘早地發現產品中的問題。

通常來說，在 Scrum 中，迭代（衝刺）週期一般為 2 到 4 周。而在 XP 中，則更有可能一週就完成一次迭代。

原則四：在整個專案開發期間，業務人員和開發人員必須天天都在一起工作

這個原則很明顯是在說明溝通的重要性。在現代社會中，我們很多人即使天天坐在一個辦公室裡，也只會通過 QQ 、微信之類的聊天工具來交流。而在敏捷中，更提倡的是面對面的溝通，而且在專案成員和客戶之間，最好也是沒有隔閡的就在一個地方辦公，而且有什麼問題都是直接能夠用面對面的說話來交流的。

當然，這真的非常難。在傳統的專案開發中，外包團隊經常會有入駐的開發形式，其實這就是為了更好的解決溝通問題。但是，在敏捷中，更提倡的是讓客戶也就是甲方派一些關鍵人物參與到乙方的工作中來。這樣就能夠快速的獲得客戶的意見，同時客戶也能夠隨時清晰地知道開發的狀態。

在這其中，除了在一起工作之外，看板是也一個協同辦公很重要的工具，還包括站會、回顧會議等等各種簡單小型的會議。如果不能在一起工作的話，或者不能面對面的工作溝通的話，這些溝通工具就完全不能發揮它們的作用。

就和前面說過的一樣，讓雙方甚至多方天天在一起工作真的很難。但總有一些方法可以解決，比如週期性地同步工作一段時間，或者由資深的業務分析師來充當“使用者代言人”。

原則五：圍繞被激勵起來的個體來構建專案。給他們提供所需的環境和支援，並且信任他們能夠完成工作

在敏捷中，人是整個專案成功非常重要的一個因素。而在傳統的專案管理中，人則是一個工具。也就是說，在傳統專案管理中，所有的人都要遵循計劃，告訴他應該做什麼，怎麼做。而在敏捷中，則是以激勵為主，不會告訴你做什麼，一切以你自己來決定。通過使用者故事來認領你要完成的工作，通過故事點數來評估自己完成的速率。團隊裡的人都會認可你的工作，也會無條件的支援你、信任你。

在這裡，我們會聯想到幾個名詞：自組織、團隊、勇氣以及尊重。在將來的學習中，我們還會見到它們的身影。

原則六：在團隊內部，最具有效果並且富有效率的傳遞資訊的方法，就是面對面的交談

不用多解釋了吧？和原則四的內容很貼切吧，在原則四中我們也講過了，面對面的交流溝通是敏捷中最重要的內容。

在人和人的交流中，面對面溝通時三大要素影響力的比率是：文字7%，聲音38%，肢體動作55%。因此，為什麼原則四要強調在一起辦公的原因也再明顯不過了。當然，我們也可以排個序，面對面說話當然是最好的，其次是視訊會議，再次是電話會議，而文件的傳遞也就是傳統意義上的郵件溝通則是最差的一種交流方式。

當然，我們並不是說禁止一切的文件交流。在某些情況下，一些 Wiki 類文件有其獨特的功用，而且是不可代替的功用。

原則七：工作的軟體是首要的進度標準

這裡又再次提到了工作的軟體，也就是正式可用的軟體。既然我們不停地迭代，不停地上線。那麼如果客戶想要知道現在的進度，直接使用線上的軟體就可以了呀。要知道，敏捷區別於傳統專案開發的一大特點就是不停地持續交付真正可用的軟體產品。

在敏捷中，一個功能無法使用，也就意味著這個功能是沒有交付的。這種情況下，進度標準就被清晰的定義為每個功能是否交付，而且只有兩個選項，已交付和未交付。當然，對於開發團隊來說可能還有更多的選項，但對於客戶來說，這兩個就足夠讓他們清晰的知道現在產品已經開發到什麼狀態了。

原則八：敏捷過程提倡可持續的開發速度。責任人、開發者和使用者應該能夠保持一個長期的、恆定的開發速度

其實說人話就是每次迭代的時間保持一致。比如我們確定好了兩週一個迭代，那麼後面就儘量不要改變這個迭代週期。另外一點則是每次迭代所完成的工作量也應該是要保持一致的。在這裡，我們會用到“使用者故事”中的“故事點”的概念。也就是每次迭代我們都應該完成相同的“故事點”功能以實現迭代中工作量的一致性。

良好的迭代規律能夠為團隊帶來歡樂和生產力。試想在一個動盪的，充滿不確定性的環境中，如何才能讓團隊保持平衡產出呢？另外，也可以將一次專案的開發比喻成一次長跑，在奧運會的長跑比賽中，解說員都會說穩定的節奏對於長跑的重要性。而短跑更像是每一次的迭代，在 Scrum 中，迭代也叫做衝刺。因此，整個專案開發過程，其實就是在穩定節奏下的一次次拼盡全力的衝刺。

原則九：不斷地關注優秀的技能和好的設計會增強敏捷能力

這一點可以說是更重視於軟體開發中的架構設計。程式碼一旦變得複雜，冗餘，就會失去敏捷性。特別是長時間積累的，經過多人之手的傳說中的“shi山”級別程式碼。之所以說不斷關注，原因其實就像我們的專案程序一樣，對於程式碼來說，也是不斷地迭代升級的，當然，它有一個更專業的名詞：“重構”。

持續不斷的重構，其實也正對應著敏捷中的一個思想，那就是不斷精進，這個概念來源於豐田的精益生產標準。而這個精益生產，也正是敏捷思想的啟蒙概念之一。把控每一個環節，消除浪費，對應到敏捷軟體開發的實踐中，就是測試先行、持續整合以及重構的綜合應用。要知道，返工和嚴重的 BUG ，正是最大的浪費來源。

原則十：簡單（盡最大可能減少不必要的工作）是一門藝術

這個原則是我最喜歡的原則，當然，相信也是不少人最喜歡的原則。敏捷從不提倡過度設計，所以，適合當下的就是最好的。即使要為將來做準備，也要在嚴謹的論證基礎上進行適當的擴充套件準備。

反過來說，這個原則最主要杜絕的其實也是一種浪費，那就是過度設計的浪費。我們經歷過太多的專案，真的是看別人有什麼就要做什麼，最後的結果卻總是不了了之了。根據28法則（帕累託），你的專案中使用者最常用的功能其實只有那麼 20% ，而剩下的 80% 可能大部分人都根本不知道。當然，也就可能剩下的這 80% 功能是為了那 20% 的使用者所準備的。不過，如果是一個迭代的敏捷開發過程，那麼我們最優先要做的，正是那 20% 的核心功能。至於如何做呢？最簡單的方式去實現他們。然後在將來不斷地重構升級。

原則十一：最好的架構、需求和設計出自於自組織的團隊

敏捷很重視個人，但其實它更在乎的是整個團隊。而在各種團隊形式中，敏捷又最推崇的是自組織的團隊。這是一種什麼樣的團隊呢？程式碼共有、人人負責、團隊計劃、自主分解、自主協作、自我約定。看著是不是感覺很美好，沒錯，這樣的團隊非常難形成。

首先，我們要有一個小而精的規模，敏捷中不提倡太大的團隊，如果人數過多，那麼混亂也就隨之而來。團隊也一樣要“簡單”。

其次，團隊成員的水平要高，甚至最好是通才。但這個太難實現了，所以，我們推崇教練機制。說白了，就是一種老帶新的機制，有專案管理教練，有編碼教練，當然也可以有產品教練，設計教練。

最後，團隊宗旨要明確，沒有目標的團隊很難取得進步，在團隊內部也很難溝通，至少，我們要為了同一個目的去工作，不是嗎？

原則十二：每隔一段時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行為進行調整

這個原則好理解，我們中國有句古話“吾日三省吾身”。這句話出自《論語》，意思就是每天都要對自己提三個問題進行反思。而在敏捷中，我們也非常重視這個反省的過程。因為我們的迭代速度快，所以有時候一些錯誤的構架和 BUG 確實是不可避免的，但是要拿出“勇氣”，敢於“反省”和“重構”。另外最重要的一點是，這些都是在團隊的基礎上進行的，也就是說，錯誤不是某一個人的，而是團隊中的問題。

在 Scrum 中，回顧會議就是非常重要的一個會議。通常在一個迭代結束之後都要進行一次回顧會議。目的就是讓團隊搞清楚我們在上一個迭代做了什麼，有哪些收穫，有哪些不足，怎麼改進。說實話，不管是團隊還是個人的進步，真像都在於我們如何去總結沉澱自己的經驗。

總結

內容有點多吧？沒辦法，畢竟十二條原則，說多不多，說少不少的。就像開頭所說的，如果是有特殊的目的來進行學習的話，那這十二條原則是必須要背的內容。

通過這十二條原則以及一些相應的解釋，相信大家看到了不少很熟悉但又陌生的名詞。別急，在後面的學習中我們還會見到並且學習到它們。

參考文件：

《某培訓機構教材》

《使用者故事與敏捷方法》

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

《敏捷專案管理與PMI-ACP應試指南》