【原】【敏捷1.2】敏捷宣言的官方解釋：12條敏捷原則

硬核項目經(jīng)理 2021-09-27

展開全文

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

在現(xiàn)實的項目環(huán)境中，各種因素往往是復(fù)雜多變的，敏捷宣言的概括雖說是可以覆蓋到大部分的問題，但畢竟還是太過于籠統(tǒng)抽象了。所以，各位大佬們在發(fā)布敏捷宣言的同時，還給出了 12 條敏捷原則，可以看成是對敏捷宣言的官方解釋及補充。

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

原則一：我們最優(yōu)先要做的是通過盡早的、持續(xù)的交付有價值的軟件來使客戶滿意

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

在這一個原則，我們就會看到幾個名詞：持續(xù)交付、客戶價值，以及為了實現(xiàn)這個原則所應(yīng)該采取的開發(fā)方式：迭代式生命周期。記住，這些名詞都和這個原則有著千絲萬縷的關(guān)系。

原則二：即使到了開發(fā)的后期，也歡迎改變需求。敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢

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

這個原則也是與傳統(tǒng)的項目管理最不同的一點，傳統(tǒng)的項目管理中，非常注重的一點就是變化是一切罪惡的根源。所有的一切應(yīng)該是圍繞著計劃進行的，變化會產(chǎn)生一系列的問題，包括但不限于時間延長、成本增加、質(zhì)量降低等等。所有的變化一定要走完善的變更流程，要有記錄，要能追溯。但是，在敏捷中，變化是受歡迎的，是值得我們?nèi)肀У?，為什么呢？就是上面的原因，它能夠提升客戶價值。

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

這個原則是順著原則二的繼續(xù)深入。快速地、短期的交付，也就是讓客戶和用戶在很短的時間間隔里就可以體驗到新的、不斷累加的產(chǎn)品功能，就能盡早地讓客戶驗證對產(chǎn)品的想法以及盡早地發(fā)現(xiàn)產(chǎn)品中的問題。

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

原則四：在整個項目開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須天天都在一起工作

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

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

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

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

原則五：圍繞被激勵起來的個體來構(gòu)建項目。給他們提供所需的環(huán)境和支持，并且信任他們能夠完成工作

在敏捷中，人是整個項目成功非常重要的一個因素。而在傳統(tǒng)的項目管理中，人則是一個工具。也就是說，在傳統(tǒng)項目管理中，所有的人都要遵循計劃，告訴他應(yīng)該做什么，怎么做。而在敏捷中，則是以激勵為主，不會告訴你做什么，一切以你自己來決定。通過用戶故事來認領(lǐng)你要完成的工作，通過故事點數(shù)來評估自己完成的速率。團隊里的人都會認可你的工作，也會無條件的支持你、信任你。

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

原則六：在團隊內(nèi)部，最具有效果并且富有效率的傳遞信息的方法，就是面對面的交談

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

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

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

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

這里又再次提到了工作的軟件，也就是正式可用的軟件。既然我們不停地迭代，不停地上線。那么如果客戶想要知道現(xiàn)在的進度，直接使用線上的軟件就可以了呀。要知道，敏捷區(qū)別于傳統(tǒng)項目開發(fā)的一大特點就是不停地持續(xù)交付真正可用的軟件產(chǎn)品。

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

原則八：敏捷過程提倡可持續(xù)的開發(fā)速度。責任人、開發(fā)者和用戶應(yīng)該能夠保持一個長期的、恒定的開發(fā)速度

其實說人話就是每次迭代的時間保持一致。比如我們確定好了兩周一個迭代，那么后面就盡量不要改變這個迭代周期。另外一點則是每次迭代所完成的工作量也應(yīng)該是要保持一致的。在這里，我們會用到“用戶故事”中的“故事點”的概念。也就是每次迭代我們都應(yīng)該完成相同的“故事點”功能以實現(xiàn)迭代中工作量的一致性。

良好的迭代規(guī)律能夠為團隊帶來歡樂和生產(chǎn)力。試想在一個動蕩的，充滿不確定性的環(huán)境中，如何才能讓團隊保持平衡產(chǎn)出呢？另外，也可以將一次項目的開發(fā)比喻成一次長跑，在奧運會的長跑比賽中，解說員都會說穩(wěn)定的節(jié)奏對于長跑的重要性。而短跑更像是每一次的迭代，在 Scrum 中，迭代也叫做沖刺。因此，整個項目開發(fā)過程，其實就是在穩(wěn)定節(jié)奏下的一次次拼盡全力的沖刺。

原則九：不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計會增強敏捷能力

這一點可以說是更重視于軟件開發(fā)中的架構(gòu)設(shè)計。代碼一旦變得復(fù)雜，冗余，就會失去敏捷性。特別是長時間積累的，經(jīng)過多人之手的傳說中的“shi山”級別代碼。之所以說不斷關(guān)注，原因其實就像我們的項目進程一樣，對于代碼來說，也是不斷地迭代升級的，當然，它有一個更專業(yè)的名詞：“重構(gòu)”。

持續(xù)不斷的重構(gòu)，其實也正對應(yīng)著敏捷中的一個思想，那就是不斷精進，這個概念來源于豐田的精益生產(chǎn)標準。而這個精益生產(chǎn)，也正是敏捷思想的啟蒙概念之一。把控每一個環(huán)節(jié)，消除浪費，對應(yīng)到敏捷軟件開發(fā)的實踐中，就是測試先行、持續(xù)集成以及重構(gòu)的綜合應(yīng)用。要知道，返工和嚴重的 BUG ，正是最大的浪費來源。

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

這個原則是我最喜歡的原則，當然，相信也是不少人最喜歡的原則。敏捷從不提倡過度設(shè)計，所以，適合當下的就是最好的。即使要為將來做準備，也要在嚴謹?shù)恼撟C基礎(chǔ)上進行適當?shù)臄U展準備。

反過來說，這個原則最主要杜絕的其實也是一種浪費，那就是過度設(shè)計的浪費。我們經(jīng)歷過太多的項目，真的是看別人有什么就要做什么，最后的結(jié)果卻總是不了了之了。根據(jù)28法則（帕累托），你的項目中用戶最常用的功能其實只有那么 20% ，而剩下的 80% 可能大部分人都根本不知道。當然，也就可能剩下的這 80% 功能是為了那 20% 的用戶所準備的。不過，如果是一個迭代的敏捷開發(fā)過程，那么我們最優(yōu)先要做的，正是那 20% 的核心功能。至于如何做呢？最簡單的方式去實現(xiàn)他們。然后在將來不斷地重構(gòu)升級。

原則十一：最好的架構(gòu)、需求和設(shè)計出自于自組織的團隊

敏捷很重視個人，但其實它更在乎的是整個團隊。而在各種團隊形式中，敏捷又最推崇的是自組織的團隊。這是一種什么樣的團隊呢？代碼共有、人人負責、團隊計劃、自主分解、自主協(xié)作、自我約定?？粗遣皇歉杏X很美好，沒錯，這樣的團隊非常難形成。

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

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

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

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

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

在 Scrum 中，回顧會議就是非常重要的一個會議。通常在一個迭代結(jié)束之后都要進行一次回顧會議。目的就是讓團隊搞清楚我們在上一個迭代做了什么，有哪些收獲，有哪些不足，怎么改進。說實話，不管是團隊還是個人的進步，真像都在于我們?nèi)绾稳タ偨Y(jié)沉淀自己的經(jīng)驗。