2.1 敏捷理論體系解讀

敏捷的內容非常豐富，本節對敏捷的理論體系的介紹主要通過如圖2-1所示的幾個方面展開。

2.1.1 敏捷背景介紹

敏捷最初于20世紀50年代被提出，并被認為是一種奇怪的、甚至無政府主義的觀點。隨后，在企業實踐過程中出現了各具特色的敏捷模型，如 XP、TDD、DSDM、自適應軟件開發、水晶系列、Scrum等。2001年2月11日到13日，17位軟件開發領域的領軍人物聚集在美國猶他州的滑雪勝地雪鳥（Snowbird）雪場。經過兩天的討論，“敏捷”（Agile）一詞被全體聚會者所接受，用以概括一種全新的軟件開發價值觀。這種價值觀，通過一份簡明扼要的“敏捷軟件開發宣言”（以下簡稱敏捷宣言）被傳遞給了世界，宣告了敏捷開發運動的開始（見圖2-2）。

敏捷提出的初衷是形成一套更加快速、更加可靠的軟件開發方法，讓軟件使用者盡可能早地看到滿意的產品。

2.1.2 三大支柱解讀

敏捷框架并非預測性的框架，瀑布源于工程學，瀑布模型是預測性的框架。由于項目立項建設周期長，在開始設計和構建之前，往往要一次性完成半年或一年的計劃，預先要進行周密規劃和立項調研。層層審批后，會形成一份長長的時間進度表。在項目實施過程中，隨著資源的變化、需求的變更，進度會產生嚴重偏差，進而導致計劃失控，陷入混亂的泥潭。敏捷范圍管理的主要特征在于，在一部分范圍明確需求后（具備前期幾次迭代的功能需求后），就開始架構設計具有不完全范圍的解決方案。在迭代過程中，不斷向產品的需求列表中添加新特性，并從客戶那里收集反饋，以便更好地理解客戶的想法，不斷完善現有產品的功能，這是自適應生命周期的主要特征之一。

敏捷有三大支柱，分別是透明度、可檢驗、自適應，如圖2-3所示。

所謂透明度就是指團隊內部不應該有秘密的小團隊，不應該有秘密的日程，也不應該有其他什么秘而不宣的事情。在組織或團隊里，如果每個人都不知道其他人在忙什么，也不清楚其他人平日的忙碌對于項目有什么貢獻，就容易產生隔閡。只要一切透明，團隊就能通過自我組織來解決顯而易見的問題。透明度高、注重信息分享的團隊工作默契程度高，效率會明顯提高。

可檢驗指的是在開發過程中經常性地停下手中的工作，對已經取得的成果進行檢查，看看這些成果是否是自己期待的，想想有沒有更好的方法來改進。這看似簡單，做起來并不容易，這需要從事相關工作的人員有思想，善于自省，具有實事求是的精神和自我約束的意識。

當團隊或個體可以進行自我管理，有能力決定如何開展工作，并獲得了如何做事的決定權后，若發現最終交付的產品無法達標、無法滿足預期，便需要對過程或工作方式進行調整。能夠調整自己的行為，意味著我們能適應任何環境，這種調整與檢驗會形成一個良好的循環，即自適應。

2.1.3 四大核心價值觀及解讀

四大核心價值觀是敏捷宣言所傳遞出的重要信息，如圖2-4所示。

下面分別介紹四大核心價值觀。

價值觀1：個體和互動高于流程和工具。

管理層習慣將管控體系想象成超級復雜的機器，并以為擁有完美的流程和工具就會帶來完美的結果，而技術人員只不過是機器中的某個配件或某道工序，他們的工作可隨時被新人取代。然而IT產品的實現過程是無形的，它是由技術人員的智慧、知識和經驗創造的，所以人員比生產流水線更重要。敏捷提出，要更關注人的績效和能力的提升，形成團隊成員默契愉快的合作關系。

價值觀2：工作的軟件高于詳盡的文檔。

說不清從什么時候開始，軟件項目的文檔越寫越多。而寫文檔是在初期設計方案時，與客戶溝通產品需求的輔助方式。我們常常發現，當客戶看到已完成開發的功能后會產生新的靈感，告訴我們他們真正想要的功能是什么樣的。使用文檔充分記錄這些過程可以還原事情的真相，但也加重了項目的負擔。當然，不是說文檔沒有意義，而是我們現在可以使用更靈活的方式來記錄信息，比如交給運維團隊的操作手冊可以是錄制好的視頻，這樣更生動，信息也更全面。

價值觀3：客戶合作高于合同談判。

要與客戶建立長期的合作關系，愿意在項目開發過程中隨時按照客戶要求進行更改。

價值觀4：響應變化高于遵循計劃。

面對市場和環境的變化，我們要接受客戶層出不窮的想法，要有適者生存的能力，不基于預測式的項目管理框架，避免前期長時間投入追求完美的設計階段。應該使用一個自適應的生命周期，因為客戶的想法是不斷浮現出來的，客戶遲來的想法不會帶來很多返工的問題，因為我們的規劃和設計也是逐步完善的。

2.1.4 12條原則及解讀

四大核心價值觀在實踐中能夠起到引導作用，但是具體實踐的時候需要進一步細化，由此引入了12條原則，如下所示。

第1條，我們最重要的目標是通過持續不斷地較早交付有價值的軟件使客戶滿意。

“客戶滿意”和“有價值的軟件”是關鍵詞。要確保我們開發的軟件產品能夠給客戶帶來真正的價值，關鍵在于開發期間與客戶密切合作。產品管理是確保客戶需求在開發期間能被正確理解的關鍵。我們應該把精力集中于對客戶而言最有價值的工作上。擁有較早交付有價值的軟件的能力是滿足客戶的關鍵。

第2條，欣然面對需求變化，即使在開發后期也一樣。為了獲取競爭優勢，敏捷掌控變化。

敏捷框架基于自適應性的開發生命周期，我們總能接受變化，因為每次我們想改變某些東西時，不需要重新規劃前期已定義的設計。除此之外，我們很樂意接受變更請求，因為每一項變更都離客戶真正的需求更近了一步。

第3條，經常地交付可工作的軟件，相隔幾星期或一兩個月，最好采取較短的周期。

開發周期和發布周期完全不同。盡管有發布周期，但我們的目標是縮短開發周期。發布周期的長度依賴于業務決策，并且和客戶的期望緊密關聯。短開發周期內的頻繁交付縮短了反饋周期并可促進團隊溝通。頻繁交付還能讓團隊及早暴露弱點并及時移除障礙，增加了敏捷性和靈活性。

第4條，業務人員和開發人員必須相互合作，項目進行中的每一天都不例外。

只要在業務和研發之間建立起橋梁，我們就能從中受益。業務人員和產品經理可以知道市場狀況、客戶需求和客戶價值，開發團隊可以知道產品和技術的可行性。

第5條，激發個體的斗志，以他們為核心搭建項目，提供所需的環境和支援，并加以信任，從而達成目標。

軟件開發是基于技術專家、團隊成員的知識儲備和經驗而開展的工作，開發過程更像是一種創造，在激發個體的斗志和創造力中，個體的自主性是關鍵因素。人在受到尊重并且有權決定自己的工作方式時通常工作得更好。每次沖刺要設定團隊明確的目標和范圍，角色職責清晰，形成自組織。

第6條，不論團隊內外，傳遞信息效果最好、效率最高的方式是面對面交談。

團隊甚至客戶工作在同一個場所是最合理的。當我們看到人們彼此交談時，信息更多以聽說的形式被傳遞，這種溝通方式稱為“滲透式”溝通，而這些交流的信息是文檔無法替代的（雖然不能否認文檔的重要性）。將每件事都寫下來簡直是不可能的，我們不應該只依靠寫文檔來傳遞重要信息。然而，如果團隊無法實現在同一場所工作，我們應該充分利用現代技術，如聊天群，盡量降低因無法面對面溝通而帶來的影響，并在日常例會時同步任務進展和問題。

第7條，可運行的軟件是進度的首要度量標準。

程序文件即使完成 99%，其代碼仍是跑不通的，這跟完成 0%是一樣的，除非技術人員能跟客戶一起找到共同的標準來溝通進展。解決這一問題的方法是，我們要與客戶同步需求待辦清單進度的完成/未完成狀態，并通過完成/未完成狀態來跟蹤需求的整體進展，以及需求測試通過/未通過的質量信息。

第8條，敏捷倡導可持續開發。責任人、開發人員和用戶要能夠共同維持開發步調穩定可持續。

每天上班打卡不是真正的目標，實現產品交付才是目標。加班似乎會讓流程變得更快，但事實上，加班會降低生產率并增加產品缺陷，從而影響產量，人越是疲勞，創造力就越低。我們寧愿保持一種可持續的步伐。

第9條，堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強。

敏捷不強調前期設計并不意味著不需要擔心設計。敏捷項目里一定是包括設計的，在每次迭代中每個需求都會有設計任務。而且，任何技術負債（代碼缺陷、架構缺陷等）都會使開發速度減慢。我們不應該讓技術負債積壓，所以要持續地進行重構，彌補發現的缺陷，持續關注架構的質量。

第10條，以簡單為本，極力減少不必要的工作量。

這種原則既適用于產品的功能特性，也適用于流程，多余的功能不要添加。所有流程應該時刻面臨挑戰。例如，這步真的需要嗎？誰會讀這個文檔？這個功能可以為客戶帶來什么價值？

第11條，最好的架構、需求和設計出自組織團隊。

架構、設計和需求會隨著項目的進行慢慢浮現，并且團隊會從中學到很多東西。一些前置、架構和設計是必要的，但是不能把它們定義在紙面上。架構師和系統工程師是管理研發團隊的一部分，不要成為“孤島”。

第12條，團隊定期地反思如何能提高成效，并依此調整自身的舉止表現。

無論我們工作做得多好，我們相信總有改善的余地。花時間反思和從經驗中學習能夠持續改進產品。

2.1.5 Scrum敏捷框架

本小節將就如何實踐Scrum敏捷框架進行說明。

1.Scrum敏捷框架簡介

敏捷框架有很多種，Scrum只是其中一種。根據2018年Scrum聯盟的報告，在敏捷實踐中，Scrum敏捷框架占55%的比例，另外還有Scrum/XP（Scrum和XP的結合）、Scrumban（Scrum和看板的結合）等方式也使用到了Scrum敏捷框架。Scrum是目前十分流行的敏捷框架。敏捷框架使用狀況如圖2-5所示。

從圖 2-5 中也可以看出，Scrum 敏捷框架是目前敏捷實踐中的主流框架，這也是我們從多種框架中挑選Scrum敏捷框架進行介紹的原因。

Scrum敏捷框架最早由Jeff Sutherland在1993年提出。Ken Schwaber于1995年在OOPSLA會議上標準化了Scrum敏捷框架的開發過程，并向業界公布。

“Scrum”一詞引自“橄欖球”。球隊成員的合作親密無間，球隊成員靈活機動地接球、傳球，并作為一個整體迅速突破防線，這個情景可能更能適應今天更具挑戰性的市場需求。

在Scrum敏捷框架中，Sprint是一個非常重要的概念，它的本意是指沖刺，一個Sprint就是一個迭代。Scrum項目通過一系列的Sprint來推進，Sprint長度通常為2～4周，它是一個時間箱。穩定的周期會帶來更好的節奏，在項目進行過程中不允許延長或縮短Sprint長度。

Scrum敏捷框架的內容也非常豐富，這里介紹其主要的組成部分，主要圍繞如何展開Sprint來進行。

● 三個角色：產品負責人（Product Owner）、Scrum教練（Scrum Master）、Scrum團隊（Scrum Team）。

● 四個活動：沖刺規劃會議（Sprint Planning Meeting）、每日站立會議（Daily Scrum Meeting）、沖刺復審會議（Sprint Review Meeting）、沖刺回顧會議（Sprint Retrospective Meeting）。

● 三個工件：產品待辦清單（Product backlog）、沖刺待辦清單（Sprint backlog）、燃盡圖（Burn-down chart）。

在本節接下來的內容中，我們將會介紹Scrum敏捷框架的組成和實踐方法。

2.三個角色

Scrum敏捷框架中包含三個角色：產品負責人、Scrum教練與Scrum團隊。

1）產品負責人

產品負責人負責建立和維護產品特性，這需要與客戶不斷地溝通和協作，決定產品應該做什么，定義產品需求，最重要的是確定需求的優先順序。總體而言，產品負責人需要具備如下4個特點。

● 產品負責人需要在相關領域內掌握豐富的專業知識。一方面，只有對團隊內部的工作流程和技術水平足夠了解，才能知道哪些事情能做，哪些事情不能做。另一方面，只有了解當前正在采用的流程，才能知道哪些事情是真正有價值的。

● 產品負責人必須獲得自主決策權。產品負責人應該被給予決策權，這樣才能自行決定產品的前景與具體實現，產品負責人應該為結果負責。

● 產品負責人必須有足夠的時間與團隊成員接觸，向團隊成員解釋清楚需要做什么，以及為什么要這么做。

● 產品負責人必須對價值負責。在商業語境下，最重要的就是收益。團隊通過每個“故事點”可以創造多少收益去評價一位產品負責人的業績。假如已知一個團隊每周完成 40個“故事點”的工作量，就可以計算出每一個“故事點”可以創造多少收益。

2）Scrum教練

橄欖球賽場的教練會盡可能地發揮上場球員的優勢，讓我們感受到每個球員由內而外地散發出一股能量，這些能量可以匯聚成一股更為強大的能量。Scrum 教練與之相比，要做的是確保團隊實現快速交付。我們常聽到 Scrum 教練與團隊成員探討：“我們如何才能做得更好？”這會引導團隊整體持續地改善自己的工作。

Scrum教練需要做到：

● 導入敏捷文化和最佳實踐，確保每個團隊成員認同和尊重敏捷的價值觀；

● 激勵團隊士氣，促進團隊合作，確保團隊富有效率；

● 幫助團隊排除干擾，確保沖刺目標的順利進行；

● 不是一位事無巨細的管理者，更像是服務于團隊的“仆人”；

● 確保團隊運作過程透明。

3）Scrum團隊

Scrum 源于經驗主義，因此穩定的團隊所積累的經驗對于規劃的判斷非常重要。相關研究表明，穩定的團隊比新組建的團隊的生產力要高。團隊成員之間的熟悉度也對產出效率和質量有著積極的影響。除了生產力方面的影響，穩定的團隊對于規劃也至關重要。每個Scrum團隊由于組成的人員不同，因此各有特色，工作節奏各不相同。強迫一個團隊盲目遵從其他團隊的工作方式，未必會有好的效果。

● Scrum團隊一般有6～9個人。

● 程序員、測試員、界面設計人員等團隊成員應當是跨職能、多樣化的，具備所謂的“T”型技能。

● 團隊成員必須是全職投入的。

● 團隊自我組織：在理想情況下，團隊成員是平等的，不分頭銜的。

● 在一個Sprint中應保持成員穩定。

● 負責將Product Backlog轉化成Sprint中的工作項目。

● 所有團隊成員協調、合作完成Sprint中的每一個規定的交付物。

3.四個活動

Scrum 敏捷框架中包含四個主要的活動，實際都是項目會議，接下來我們將對每個會議的目的、形式、結果進行說明。

1）沖刺規劃會議

每個沖刺都將沖刺規劃會議作為開始，這是一個固定時長的會議（不超過4小時），在這個會議中，Scrum團隊共同選擇和理解本輪沖刺要完成的工作。

會議形式包括如下兩項議程。

第一項議程：首先由產品負責人介紹產品，確定該Sprint將要完成什么任務。產品負責人向團隊明確產品待辦清單中優先級最高的產品，與團隊一起明確沖刺目標，基于團隊的能力和以往沖刺的速率一起決定沖刺中需要完成的產品數量。

第二項議程：Scrum 團隊研究本輪沖刺如何完成要交付增量的工作產品或功能。Scrum 團隊對沖刺需要完成工作產品的數量和復雜度達成共識，對需求充分理解并進行估算，將產品待辦清單中的內容轉化成軟件開發中的具體工作任務。任務需要被分解，以便在一天之內完成。團隊通過自己認領的方式獲取任務。

會議結果：每個團隊明確本輪沖刺的目標，每個人明確本輪沖刺各自的具體工作任務。

2）每日站立會議

會議目的：Scrum團隊通過每日站立會議來確認他們仍然可以實現Sprint的目標。

會議形式：由Scrum團隊自己組織，條件允許的話，每天都應該在同樣的時間和地點組織所有成員站立進行。只有團隊成員可以在例會上發言，其他人員有興趣可以參加，但只能旁聽，不能發言。最好是每天早晨進行，會議時長一般為15分鐘左右，時間比較短，有利于團隊成員安排好當天的工作。

Scrum團隊所有成員輪流回答以下3個問題。

● 昨天我完成了什么工作？

● 今天我打算做什么？

● 我在工作中遇到了什么困難，是否阻礙了我的工作進展？

3）沖刺復審會議

會議目的：沖刺復審會議用來演示在這輪沖刺中開發的產品功能，由產品負責人進行確認。產品負責人也可以邀請相關的人參加。

會議形式：

● 團隊按沖刺計劃，逐個介紹并現場演示這次沖刺完成的功能。

● 如果產品負責人想要改變功能，則需要添加到新的需求列表中，出現的缺陷也要加入缺陷列表中。

● 如果項目遇到障礙一時無法解決，把該障礙加入障礙類列表中。

● 不需要太正式，不需要PPT，會議時長控制在2小時以內。

會議結果：對這次沖刺的成果和整個產品的開發狀態達成共識。

4）沖刺回顧會議

會議目的：團隊的定期自我檢視，全體成員討論有哪些好的做法可以形成團隊的規范，哪些不好的做法不能再繼續下去，以及哪些好的做法要繼續發揚。

會議形式：

● 會議時長一般控制在15～30分鐘。

● 每個沖刺都要做。

● 全體參加。

不管我們發現了什么問題，我們必須懂得并堅信每個人通過他們當時所知的，以及所擁有的技能和可得到的資源，在限定的環境下，可以做出最好的成果。

會議結果：讓每個人都了解開發過程是什么樣的，沖刺結束后需求或任務的完成標準是什么。

4.三個工件

除了三個角色與四個活動，Scrum 敏捷框架中還包含三個工件：燃盡圖、產品待辦清單、沖刺待辦清單。

1）燃盡圖

使工作透明化的工具之一就是燃盡圖，在圖 2-6 中，橫軸代表本輪沖刺的工作天數，縱軸代表工作量，用于跟蹤團隊成員沖刺剩余天數可用的工作量和實際剩余任務的工作量。隨著剩余天數的減少，剩余任務的工作量也逐漸減少，在理想情況下，最終剩余天數和剩余工作量會延展向下，“燃盡”至零。

接下來通過一個案例來展示項目中燃盡圖的使用方式。假設在某個項目中共有5天的沖刺時間，在這個沖刺中相關人員所分配的任務信息按照預測和實際進行了每日更新，如圖2-7所示。

有了這樣的信息，團隊成員在當前沖刺的可用工作量和實際工作量的關系就能以“燃盡”形式體現出來，如圖2-6所示。

2）敏捷待辦清單

敏捷待辦清單分為產品待辦清單和沖刺待辦清單。產品待辦清單就是傳統的需求清單，也稱為需求池，它是項目最終需要交付的功能藍圖，是預期的最終產品的愿望清單，這個清單列出了所有的功能，是有序列表，而且是動態的，將包括不斷完善和細化的需求。這些需求都用簡單的、非技術的、商業的語言來描述，我們稱之為故事，所有的故事對項目每個干系人都是可見的。項目的每一個要求和每一個變化都將以用戶故事的方式進行描述。沖刺范圍內的故事，也稱為沖刺待辦清單，是優先級最高的用戶故事。

5.用戶故事和產品增量

除了三個角色、四個活動、三個工件，在Scrum敏捷框架中還有一些重要的概念，比如用戶故事和產品增量。

1）用戶故事

相較于傳統的需求分解，在敏捷中，故事的寫法也非常重要。要想學會寫用戶故事，要思考客戶可以從產品中得到什么價值，為什么要給客戶提供這樣的價值，或用戶為什么會需要這些價值。按照敘事思維來組織用戶故事，比如作為 X，我想要Y，所以做 Z。設計用戶故事時可以加入用戶使用場景，這是一種融入用戶體驗的設計思維。

用戶故事的編寫，可以通過如圖2-8所示的INVEST原則來進行，具體說明如下。

● 獨立的：如果用戶故事不是獨立的，將無法根據其業務價值對其進行排序。價值排序是可以調整的，在每次沖刺總結后都可以重新定義故事的優先級。如果不能完全獨立，就要將相關的解決方案盡量合并在一起，在同一輪沖刺中完成。

● 可協商的：產品故事的定義要便于溝通，與內部團隊及客戶之間是可以協商的，通過協商可以完善需求的各個細節和解決方案。

● 有價值的：每個故事都應該能體現其對產品整體的商業價值，評判故事價值應盡可能使用可量化的標準，量化的價值是產品故事的排序依據。

● 可估計的：只需對產品待辦清單頂部的故事進行估計。未明確和細化的故事因為需求和方案是不確定的，所以沒有估計的價值。在每次的沖刺啟動會中，要對本輪沖刺的故事重復估計。

● 小的：只有產品待辦清單頂部的用戶故事是最小的，不清晰的故事是難以估計的，應該排在待辦清單的下方。

● 可測試的：故事的定義要包括驗收標準，驗收標準可以作為用戶故事的補充，也可以作為工作完成準則（Definition of Done，簡稱為DoD）的一部分。

2）產品增量

產品增量指的是沖刺結束時，開發團隊基于沖刺待辦清單完成的功能總和。產品負責人可以接受團隊完成的功能，也可以拒絕未滿足產品經理要求的功能，未完成的功能需要重新整理到產品待辦清單中，如圖 2-9 所示，隨著完成的功能增量的增加，產品待辦清單中的故事數量隨著沖刺迭代而降低。