為什麼提倡敏捷？

20世紀50年代~90年代，能夠供會議通信場景和信息交流場景的基礎條件並未達到讓人們信息互通如同今日那般（2021）可以透過屏幕可以看到對方的面部表情。

市場的信息交流並不頻繁，用今天的視野去看，當時的商業環境進展是及其緩慢的，企業從信息傳達，到落地可能需要數個月的時間，那個時候對於領導者的前瞻性眼光要求比今日高得多了，並非說今日的商業環境不需要前瞻性眼觀了。

對比20世紀50年代~90年代的商業環境，現今的商業環境出現了翻天覆地的變化，並且通信基礎已經使得錢在地球上轉一圈只需要8秒，人們可以隨時隨刻的開啟視頻會議，從決策的決定到傳達到落地層只需要打開通信設備即可傳達。

現今人們接收到的信息也越來越多，思想、思維每天都受這些信息的影響，下一步的行動可能也會受到這些信息的影響。整個商業環境每天都日新月異的。這迫使企業更快的做出決策，更快的推出新產品到市場。

每個管理者，每個企業家都知道，企業一旦做大了，人員多了，很難很快的推出新產品。如同一個籃球運動員的身材發展那般。如果退役不打籃球了，那麼身材很容易發福，一旦發福了，那麼運動速度就會慢起來。即便這名運動員想要重新回到賽場，但是也要通過重新鍛煉腰、腿、手等各個部位，注意是各個部位。那麼企業能否也像運動員想重新回到賽場那樣，把團隊進行簡化，小步快跑的方式來去實現這種拉動。在投籃時（新產品），身體可以迅速、華麗、敏捷的投入。

什麼是敏捷？

這個問題相信無數學過敏捷，看過敏捷的書的小夥伴都會有這樣的一個疑問在心底，什麼是敏捷？怎麼樣才算是敏捷？這沒有一個標準的答案，因為每一種管理方法論都是基於不同公司自身的發展和企業文化進行裁剪過的。

敏捷就是基於目前商業環境中，客戶對價值交付的要求日趨緊迫。敏捷技術和方法將有效的管理各種顛覆性技術，特別是新的設計，和之前未做過的工作都是探索性的，隨着可確定的工作日益實現自動化，項目團隊也越來越多從事高度不確定的工作。

此外，敏捷第一原則將客戶滿意視為最高要求。為保持競爭優勢，與時俱進，各組織不能只關注內部，而是要放眼外部世界，關注客戶體驗。

小型組織和初創公司能夠更快的生產出滿足客戶需求的產品。商業環境的不斷變化將繼續促使大型公司採用敏捷思維模式，以保持競爭力和現有的市場份額。

小結：為了在短時間探討可行性，根據評估和反饋快速調整，在這個調整過程中大公司，通過化整為零，大團隊化小團隊實現小步快跑的方式。

敏捷的優點

團隊成員成就感、歸屬感更強。

更快的讓產品投入到市場，產品價值可以儘快的得到市場的驗證並修正。

敏捷的缺點

需求同步開發帶來返工風險。

避免工作轉換時的效率降低（20%~40%），團隊成員技能要求盡量具備全棧技能，俗稱的T型人才。

項目生命周期類型

每個項目都有屬於各自的生命周期類型，傳統的生命周期是預測型生命周期，又稱瀑布流生命周期。每次開發時，都假定了目標是明確的，需求是明確的，需求是不會改變的。

增量型生命周期：在前期定義了一個電商產品，在規劃中是劃分成直通車模塊、購物車模塊、活動會場模塊。第一次發佈時，就發佈了直通車模塊。本來在下一個版本中，是要發佈購物車模塊的，但是基於市場反饋，馬上就要過節了，有一個活動會場可以更好的吸引用戶。於是在下一次版本中，發佈的是活動會場模塊。整體順序就變成了直通車模塊、活動會場模塊、購物車模塊。

​

迭代生命周期：可以幫助團隊交付和反饋創建一個節奏，並且團隊會為交付和反饋創建增量。

​

敏捷生命周期：

​

小結：每一種生命周期都有各自的特點，在很多時候大多數實際情況中，是根據實施環境的不同，來組合生命周期的使用。如在前期的設計中使用瀑布流生周期，在項目開發過程中，使用敏捷型生命周期。而且在大多數企業從傳統項目管理過渡到敏捷時，普遍都會經過增量型生命周期。

敏捷的核心思想

敏捷的價值觀

1、個體互動高於流程工具：項目執行者始終是人，人是項目的核心，有優秀的成員，但是沒有好的流程來去控制的話，就會讓優秀的成員在做事時就像無頭蒼蠅最後感到心灰意冷。現在競爭越來越激烈，企業是依然需要規則、流程，並不是說不需要流程，在走流程的這個過程中沒有良好的溝通就無法更好的促進項目成功，甚至會失敗。

2、可用軟件高於完備文檔：無論對於誰來說看得見、摸的着的高質量軟件（工作成果）才是有價值的，如果看不見、摸不着停留在口頭上的東西誰會信。在產出工作成果的過程中，如果沒有文檔的話，將會是一場災難，這個工作成果只有這個完成的人知道，敏捷一樣也是需要文檔，強調的是輕量級、高價值的文檔，比如把日報改為周報。

3、客戶合作高於合同談判：大多數公司與客戶談好軟件的價格，客戶扔下一筆錢在這之後，等全部工作完成了才與客戶進行溝通與交付，結果做出來的東西是不符合客戶預期的。經常的與客戶保持溝通，每個裡程碑做好後都與客戶進行交流確認，及時發現問題、改進問題，而不是等客戶發現了才來改。如果是客戶發現問題，客戶會出現不信任的心理，甚至會出現隨意修改的過程。

4、響應變化高於遵循計劃：敏捷並不是不需要計划了，而是有更多的計劃和規劃，盡量的把不確定性控制在可控的一個時間範圍內。畢竟減少不確定性的唯一辦法是通過做一些事情或模擬來獲得反饋，不斷的根據反饋來調整計劃，即規劃-執行-調整，有點類似戴明環的PDCA。

敏捷的原則

1、目的：儘早持續交付有價值的軟件來滿足客戶需求，進而使客戶滿意。

2、態度：敏捷變更是提倡價值變更，所以是歡迎需求變更。

3、關註：儘早、經常的交付可用的軟件。

4、合作：業務與開發合力推到信息孤島的那堵牆。

5、核心：人是項目的核心，激勵項目人員，基於所需要的環境與支持。

6、溝通：盡量面對面溝通。

7、標準：可用的軟件是衡量的首要標準。

8、倡導：敏捷不提倡加班，提倡始終保持步調穩定前進，急功近利會使得團隊容易處於崩潰的狀態。

9、追求：對卓越技術和設計的持續關注與完善，以提高項目敏捷性。

10、根本：盡量減少不必要的工作，如果可以使用最簡單的方式實現需求是最好的。重構是在實現新需求的過程中，清楚冗餘的代碼，隨時重構是為了防止系統混亂的重要途徑。

11、團隊：最佳的架構、需求和設計出自於自組織的團隊，整個團隊共同承擔責任，並且任務是以團隊為單位來分配的。

12、調整：團隊定期的反思、回顧、總結經驗。項目結束時，才進行總結的話，在於總結經驗不能立刻對組織或項目帶來實際上的幫助。相反隨時進行總結，團隊成員們會認識到問題，並推動自己的行為來解決問題。

敏捷章程

項目章程：就能了解項目之所以重要的原因、團隊的前進方向以及項目的目標。幫助團隊學習如何一起工作，怎樣圍繞項目協作。團隊至少還需要項目願景和目標。為什麼要做這個項目？誰會從中受益？如何受益？達到哪些條件才意味着項目完成？我們將怎樣合作？

團隊章程：團隊價值觀，可持續的開發速度和核心工作時間；工作協議，時間盒、完整性和工作過程限制；基本規則，會議發言規定；團隊規範，對待會議時間。

主流的敏捷方法論

項目就是干已確定的工作和不確定的工作。傳統的軟件開發模型，瀑布模型是將所有工作都認為是不變的，識別變化延遲到最後的測試或用戶使用階段才發現，反饋周期很長，極大的增加了返工或變更成本。從而可以看到傳統軟件開發的官僚化，速度慢，龐大的問題。

敏捷通過短周期迭代，儘可能早的交付可用的迭代來快速響應和適應變更。

極限編程（XP）

極限編程是肯特貝克1996年提出的。

XP核心價值觀

簡單：從最簡單的入手，在通過不斷重構來達到最好的效果。

溝通：鼓勵經常性的口頭交流與反饋。

反饋：系統的反饋（測試單元）、客戶的反饋、小組的反饋。同時在編程中的樂觀主義是危險的，而及時反饋則是解決它的問題。

勇氣：只為今天的需求而編碼，不要考慮明天。這是為了避免陷入設計泥潭而在其他問題上花費太多不必須要的精力，進而知道什麼時候該丟棄現有的代碼。

尊重：團隊成員之間體現在每個人保證提交的如何改變不會導致編譯無法通過，或者導致現有測試用例失敗。堅持追求高質量，堅持通過重構的手段來為手頭上的工作找到最好的解決涉及方案。

XP生命周期

在XP中，輕量級的需求被叫做用戶故事，通常用於發佈和衝刺計劃中。

典型衝刺有2周的時間：

1、在這衝刺期間開發人員會以結對編程的方式編寫代碼；

2、所有開發好的軟件都會進行嚴格的而頻繁的測試；

3、在獲得客戶認可之後，才會小規模的發佈；

備註：探針是一種技術方法，是為了減少風險，並且探針會在整個發佈中使用到。例如在學習新技術、評估、驗收標準定義以及通過產品了解用戶行為的流程中應用。

XP核心實踐

完整的團隊：客戶、開發人員、測試等都在一個場所下工作。

規劃遊戲：需求分析都是通過規劃遊戲完成的。這個過程分為三個階段：探測，分解需求；計劃，制定和發佈計劃；調整，根據實際情況調整計劃。

小型發佈：非常短的周期內以遞增的方式發佈新版本。體現了敏捷的特性。統一軟件開發過程強調衝刺開發。

共同所有權：全部代碼強調所有人都要負責，某個人的代碼出現BUG，另一個人可以修復。並且執行嚴格的代碼控制。

編碼標準：如果沒有統一的編碼標準，代碼共同所有權就無從談起了。

可持續的速度：強調以恆定的速率進行工作，不強調加班。

隱喻：在溝通中常用比喻的方式，加速理解。

持續集成：及早的爆率並消除隱患，由於重構、集體代碼所有權的引入，從而減少問題的痛苦。

測試驅動開發：越沒有空寫測試程序，代碼的效率和質量就越差，花在找BUG，解決BUG的時間就越長。

重構：是一種對代碼進行改進，而不影響功能實現的技術。

簡單設計：認為設計部應該在編碼之前一次性完成，那樣只能建立在需求不會改變的或者可以預見所有的變化的基礎上。並且要能夠通過所有測試程序，沒有包括任何重複的代碼，清晰的表達帶來所有意圖，儘可能少的類和方法。

結對編程：一個人寫程序，另一個人坐在一邊看，大大的降低了溝通成本，提高了工作之類，代碼至少有2個人熟悉，並且代碼總是能評審過，還能夠消除無謂分歧、更好的溝通。

XP小結

XP核心價值觀：簡單；溝通；反饋；勇氣；尊重；

XP生命周期：用戶故事、2周衝刺、結對編程、嚴格測試、小規模發佈。

XP核心實踐：完整的團隊；規劃遊戲；小型發佈；共同所有權；編碼標準；可持續的速度；隱喻；持續集成；測試驅動開發；重構；

Scrum

Scrum來源於美式橄欖球，每個團隊成員都具備很強的進攻和防範能力。團隊成員具有高度自主權，在比賽中進行緊密的溝通合作，以高度彈性解決各種問題。

備註：接下來的所有講解將按照Scrum的方法論進行講解。

Scrum核心理念

透明性（Transparency）：軟件開發過程中各個環境保持高度的可見性。

檢驗（Inspection）：定期的檢查並總結經驗，發現改進地方。

適應（Adaptation）：如果檢查發現過程中有一個或多個方面不滿足驗收標準，並且最終產品是不合格的，那麼就要進行調整，調整工作必須加快實施，以減少進一步的偏差。

Scrum團隊組成

產品負責人（Product Owner）

職責：從市場獲得信息，確定該產品對於企業的回報，並且及時將市場需求反映在產品待開發項中。並且PO對產品待開發項具有決策權的人，重新排列產品待開發項優先級需要得到PO的統一，所有成員都要尊重PO的決定。

對產品待開發項的內容進行優先級排序；

確保開發團隊所執行工作的價值；

確保開發團隊對產品待開發項內容達到一定程度的理解；

Scrum Master（教練）

清晰的傳達願景。

提供食物和水。

清除團隊成員的障礙，如頻繁的開無意義的會議。

開發團隊（Team）

自組織的團隊：沒有人會告訴開發團隊如何把產品待開發項列表變成潛在的可發佈的功能，自己決定做什麼Scrum Master也不能干預。

跨職能：團隊擁有創造產品增量所需要是全部技能。無論承擔什麼工作都是開發者，不認可頭銜，以及不包括測試、業務、分析等特定領域的團隊，每個人統稱都是成員。

團隊規模：建議3-9人，5-9人最適合。

Scrum的開發流程

​

1、PO從市場或客戶方獲取相關的產品信息。

2、PO一個人或與團隊共同梳理收集回來的需求，並採用用戶故事的方式對需求進行梳理。

3、根據使用用戶故事梳理出來的需求，排列需求優先級，形成產品待開發列表（Product Backlog），並確定此次要發佈計劃要完成的工作內容。

4、PO、開發團隊、SM等涉及的相關方，共同召開衝刺規劃會議。這個會議會持續4~8小時。PO向開發團隊介紹產品待開發項列表，確保與開發團隊對這些工作取得共同的理解

5、開發團隊在衝刺規劃會議上挑選出一些用戶故事並細化成任務作為本次衝刺的目標，並形成衝刺待辦列表（Sprint Backlog）。

6、每一輪衝刺（Sprint）持續時間約2~4周。衝刺（Sprint）開始時，開發團隊成員根據意願領取自己想要做的任務。

7、每天早上會花15分鐘召開每日站會（Daily Scrum Meeting），每個團隊成員會回答三個問題，昨天完成了什麼？今天準備做什麼任務？遇到什麼障礙？

8、在本輪衝刺完成後，會召開衝刺評審會議（Sprint Review Meeting），會持續2~4小時。主要是向相關方演示本次完成的產品功能，並獲得反饋。同時，可以討論並計划下一個迭代要做的事情。

9、召開衝刺回顧會議（Sprint Retrospective），持續時間2~4小時。總結哪些做的好的地方需要保持，需要改進的地方有哪些，以便在下一個衝刺中進行改進。

10、本輪迭代結束。

Scrum活動或會議

衝刺（Sprint）

一個衝刺就是一個時間盒，時間大約是2~4周。

每個衝刺中包括了衝刺計劃會議、每日站會、衝刺評審會議和衝刺回顧會議。

衝刺規劃會議（Sprint Planning Meeting）

持續4~8小時，確定在這個衝刺中需要交付哪些產品功能，以及如何達成目標。

PO向團隊介紹排好優先級的產品待開發項，確保開發團隊對事項的理解，創建足夠詳細的計劃來確保其能夠完成。

本輪衝刺要完成的待開發項數量的多少由開發團隊自行決定去評估和決定，SM或PO都不能干預。決定如何完成工作是開發團隊的職責，決定做什麼則是PO的職責。

開發團隊按照完成的定義分解更小的單元，每個工作單元不超過一天。PO可以繼續留下來回答問題以及澄清一些誤解。

每日立會（Daily Scrum Meeting）

持續15分鐘，可以帶來透明性、信任和更好的績效。

上一個每日立會到現在完成了什麼？從現在到下一個每日立會，計劃完成什麼？遇到了什麼障礙？

衝刺評審會議（Sprint Review Meeting）

持續2~4小時，演示此次衝刺完成的產品功能，並獲得客戶的反饋與PO的驗收。

PO和團隊還可以根本此次完成的產品功能做對應的調整，並討論剩餘的產品待開發項（此次未完成或下一個階段做的產品開發項），以及下一步計劃完成的工作。

衝刺回顧（Sprint Retrospective）

持續時間不超過3小時，總結哪些做的好的地方需要保持，需要改進的地方有哪些，以便在下一個衝刺中進行改進。

Scrum工件

產品待開發項（Product Backlog）

包括業務功能和非業務功能（技術、架構和工程實踐相關等），提升點及缺陷修復等。

產品待開發項是需要持續改變的，以確保優先級是最合理、最具有競爭力、最有價值的。

Scrum不考慮已經花在產品待開發項內容上的工作時間，只關心剩餘工作和日期這兩個變量。

衝刺待開發項（Sprint Backlog）

是從產品待開發項的用戶故事分解而來的一系列任務項。

會伴隨有一個計劃以實現本輪衝刺的目標，並且產品待開發項的功能點被放到衝刺的固定周期中。

衝刺待開發項會因為兩個方面而變化：一是對需求有更好的理解，可能需要增加一些新的任務到衝刺待開發項中。二是缺陷作為新的任務加進來，這個都作為承諾提交任務中未完成的工作。

通過衝刺中不斷追蹤剩餘的工作，開發團隊可以管理自己的進度。

增量

在一個衝刺完成之後的所有產品待辦事項的綜合，以及之前所有衝刺產生的增量價值的總和。這些總量在每個衝刺即將結束的時候必須滿足完成的定義，並且能夠帶來價值。

Scrum小結

Scrum價值觀；Scrum原則；

Scrum團隊組成由PO、SM、開發團隊。

Scrum的開發流程。

Scrum活動或會議有衝刺規劃會議、每次站會、衝刺評審會議、衝刺回顧會。

Scrum工件：產品代辦列表、衝刺代辦列表、增量。

​