《說透敏捷》是極客時間上的付費課程，里面有很多案例，如果想學(xué)習敏捷知識，建議去購買。以下是我在學(xué)習過程中的筆記，并不是原文。
01 | 敏捷有很多益處，但不是萬能的
敏捷是一場變革，它本身涉及人的習慣、團隊文化的改變等等，它的核心點是持續(xù)改進。它有一定的章法，但是若想運用好它，又不能拘泥于它的章法。使用敏捷的目的是解決問題，若用其他辦法能解決問題，也可不必使用敏捷的方法，千萬不要為了敏捷而敏捷。總之，能夠更好地解決問題就好。
1. 瀑布模型
研發(fā)的整個工作流程是按順序進行的。即先做需求調(diào)研，再做開發(fā)、測試、驗收和上線，所有工作都是串行的，只有達到下一步的準入標準，我們才進行下一步工作。瀑布模型是 1970 年提出的，盛行于20 世紀 80 年代。瀑布模型使開發(fā)人員感受到各種束縛，研發(fā)效率受到阻礙。
2. 瀑布模型的缺點
研發(fā)周期過長，導(dǎo)致研發(fā)跟不上業(yè)務(wù)發(fā)展的節(jié)奏。在瀑布模型中，所有的工作都是串行的，只有前序環(huán)節(jié)完成，才能展開后序環(huán)節(jié)，大量人力與時間成本都在這段時間里被白白消耗，等產(chǎn)品開發(fā)出來推向市場，很有可能市場已經(jīng)沒有了，或者業(yè)務(wù)已經(jīng)發(fā)生了很大變化。
研發(fā)不能很好地響應(yīng)需求變化，導(dǎo)致客戶滿意度低。我們很難在設(shè)計之初就把所有的需求想清楚，需求又是不斷變化的，客戶在看到真正的產(chǎn)品之前，對產(chǎn)品很可能是無感的。瀑布模型是在項目最后才一次性地向客戶交付產(chǎn)品，這時客戶才發(fā)現(xiàn)他們需要的不是這個東西，這是非常可怕的事情。
不能很好地管控風險。因為是研發(fā)最后一次性交付，所以項目中的很多風險在前期很難被完全識別出來，最后發(fā)現(xiàn)時再想處理就要付出更大的代價。
軟件研發(fā)具有強烈的不確定性。而瀑布模型，其流程和步驟都是規(guī)定好的，且計劃與生產(chǎn)分離，更適合確定性高的工作。在這種不確定性很高的研發(fā)工作面前，我們以處理確定性高的工作的方式和流程來進行管理，毫無疑問是不奏效的。
3. 針對瀑布模型的改進
組織結(jié)構(gòu)：我們的團隊應(yīng)該由一個個小的團隊組成。團隊是固定的，成員也基本是固定的，這樣我們不需要花費時間去組建團隊，磨合團隊。
需求梳理：邊梳理邊跟客戶交流。不要花幾個月去梳理并在最后才給客戶看我們梳理的結(jié)果。要把需求按優(yōu)先級排序形成需求池，迭代地進行研發(fā)。
讓客戶積極地參與我們的研發(fā)過程。包括前期的需求調(diào)研和后面的開發(fā)測試上線，迭代有產(chǎn)出時就讓客戶驗收，讓他們提意見，以便我們在后面的迭代隨時調(diào)整。
4. 不適合做敏捷的情況
產(chǎn)品本身的容錯率很低，不允許試錯；用敏捷的話與投入產(chǎn)出不成正比；公司需要深遠地考慮戰(zhàn)略問題。
02 | 敏捷到底是什么？
敏捷的誤區(qū)
1.敏捷就是再也不用寫文檔，不用做設(shè)計了。我們只負責寫代碼。
2.敏捷就是快。原來 6 個月才能完成的項目只用了3個月就完成了。
3.敏捷就是加班。采用敏捷后，我們比原來加班更嚴重了。
4.Scrum 就是敏捷，敏捷就是 Scrum。
5.敏捷是自由的、無約束的。不需要那么多條條框框，跟隨自己的心來做就好了。
敏捷的價值觀
1.個體和交互勝過過程和工具
2.可以工作的軟件勝過面面俱到的文檔
3.客戶合作勝過合同談判
4.響應(yīng)變化勝過遵循計劃
5.雖然右項有價值，但我們更重視左項（與每一條中右面的內(nèi)容相比，左面的內(nèi)容是敏捷更加重視的，但并不表示停止做右面的內(nèi)容）
撥亂反正
1.敏捷重視可工作的、有價值的軟件，減少一切不必要的文檔。注意是不必要的文檔，而不是所有文檔。不必要的文檔：交接類文檔，比如提測文檔。必要文檔：系統(tǒng)設(shè)計文檔、接口文檔、數(shù)據(jù)庫設(shè)計文檔等。
2.敏捷的快不是指敲代碼的速度加快了。敏捷的快是針對交付，盡早交付可用的軟件給客戶，而不是最后一次性交給客戶，并且交付的間隔時間越短越好。所以敏捷中的“快”指的是反饋更快，反饋更及時。敏捷的原則下，客戶的目標達到才意味著項目可以結(jié)束，短迭代使客戶對自己的需求更清楚了，有可能做的事情更少了，所以時間才減少了，交付也更快了。
3.“敏捷就是加班”這個理解有失偏頗。敏捷原則第8條：“敏捷過程提倡保持長期的、恒定的、可持續(xù)的開發(fā)速度”，不是為了加速開發(fā)而加班，透支團隊成員的健康。
如何保持可持續(xù)的開發(fā)速度呢？
1.迭代開始的時候，不要過度承諾，能完成多少工作，就承諾多少工作。
2.嚴格遵守紀律。迭代開始之后，原則上不再接受增加需求，如果一定要增加，就要從迭代中減少等量的其他的需求。
敏捷的原則
1.我們最優(yōu)先要做的是通過盡早的、持續(xù)的交付有價值的軟件來使客戶滿意。
2.即使到了開發(fā)的后期，也歡迎改變需求。敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢。
3.經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。
4.在整個項目開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須天天都在一起工作。
5.圍繞被激勵起來的個體來構(gòu)建項目。給他們提供所需的環(huán)境和支持，并且信任他們能夠完成工作。
6.在團隊內(nèi)部，最具有效果并且富有效率的傳遞信息的方法，就是面對面的交談。
7.工作的軟件是首要的進度度量標準。
8.敏捷過程提倡可持續(xù)的開發(fā)速度。責任人、開發(fā)者和用戶應(yīng)該能夠保持一個長期的、恒定的開發(fā)速度。
9.不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計會增強敏捷能力。
10.簡單——使未完成的工作最大化的藝術(shù)——是根本的。
11.最好的構(gòu)架、需求和設(shè)計出自于自組織的團隊。
12.每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然后相應(yīng)地對自己的行為進行調(diào)整。
敏捷的方法和實踐
敏捷方法包括：極限編程、Scrum、特征驅(qū)動開發(fā)、動態(tài)系統(tǒng)開發(fā)方法、自適應(yīng)軟件開發(fā)、水晶方法等等。規(guī)模化敏捷的方法，比如SaFe 和 Less；技術(shù)實踐，比如測試驅(qū)動開發(fā)。這些方法都遵守了敏捷的價值觀和原則，不同的是它們針對了不同的應(yīng)用場景，比如說 Scrum 在新軟件開發(fā)中更好用，而看板在維護類的軟件開發(fā)中更勝一籌。
Scrum 框架的“三三五五”：3 個角色（產(chǎn)品負責人、團隊、ScrumMaster)，3 個工件 (產(chǎn)品待辦事項列表、迭代待辦事項列表、燃盡圖），5 個會議（迭代計劃會議、每日站會、迭代回顧會議、迭代評審會議、產(chǎn)品 Backlog 梳理會議），5 個價值（承諾 、專注、開放、尊重、勇氣）。
Scrum 的約束條件：1.迭代計劃會議開始前，產(chǎn)品負責人需要準備好需求條目，使需求達到準入標準；2.Scrum 講究時間盒，包括迭代的周期、各個會議，這些都要遵守時間盒的約定。
建議使用敏捷每一種方法前問自己3個問題：1.這個方法能解決什么樣的問題？2.有沒有使用前提？3.有沒有相應(yīng)的使用規(guī)則？
敏捷 = 價值觀 + 原則 + 一系列符合價值觀和原則的方法。
03 | 敏捷成功第一步：評估診斷
評估診斷的4步
第一步：挑選代表性項目。可以是業(yè)務(wù)上有代表性，也可以是研發(fā)模式上有代表性的項目。如果企業(yè)的項目囊括了大、中、小型項目，建議把大、中、小型項目各選一個來進行評估。
第二步：訪談評估。對選定項目中的開發(fā)、測試、運維、需求、項目管理人員等人員，依次進行訪談，主要是為了全面了解項目的研發(fā)流程，了解每個角色在研發(fā)活動中的工作情況，也了解各個角色之間的協(xié)作情況。從流程、組織、人員技能、度量和技術(shù)等維度，對項目進行深度評估，有意識地詢問和探查項目的痛點。
第三步：制定轉(zhuǎn)型計劃。根據(jù)發(fā)現(xiàn)的問題和痛點，做推進敏捷的計劃，痛點不同，計劃也不同，要有針對性地做計劃方案。比如團隊的主要問題是跨部門、跨團隊溝通協(xié)作不暢，在敏捷計劃中就要優(yōu)先考慮團隊組織的問題，必要時做組織變革；再比如團隊的問題集中在從開發(fā)完成到上線前這一段，在計劃中就要優(yōu)先考慮建設(shè) DevOps 流水線。
第四步：溝通。在訪談評估和制定計劃后，正式進行敏捷實踐前，需要與相關(guān)干系人，例如團隊成員、團隊主管，以及推進敏捷的內(nèi)部負責人等，就評估結(jié)果和相應(yīng)計劃進行溝通，以便整個團隊達成一致意見。
04 | 試點前準備
選擇兩個或兩個以上、采納敏捷的意愿相對強烈、業(yè)務(wù)價值高或采納敏捷會在短期內(nèi)帶來很大收益的團隊進行試點。
前期準備工作細則：
組織和人員準備。組織結(jié)構(gòu)要高內(nèi)聚、低耦合。高內(nèi)聚指全功能小團隊內(nèi)部成員之間的溝通合作更緊密；低耦合則指團隊之間的溝通協(xié)作要遠比團隊內(nèi)部的少。團隊人數(shù)被限制在5-9個人，每個團隊都有產(chǎn)品經(jīng)理、開發(fā)、測試等人員。敏捷培訓(xùn)：進行敏捷思想基礎(chǔ)和敏捷實踐基礎(chǔ)兩門基礎(chǔ)課程培訓(xùn)；組織拆書會，選擇一些敏捷基礎(chǔ)的書籍，每個人都來讀一節(jié)，一起來分享。宣講：如其他公司是怎么做敏捷的，取得了什么成效等。隨時講解：需求條目化、怎么做用戶故事及如何拆分。
管理治理規(guī)則準備。如架構(gòu)和設(shè)計的治理規(guī)則，質(zhì)量管理策略規(guī)則等。
需求范圍的前期準備。項目的高階需求范圍、高階發(fā)布計劃；高階的史詩級故事；近期 2 個迭代要開發(fā)的用戶故事。用戶故事要有優(yōu)先級排序，要有故事描述，還要有驗收標準。
架構(gòu)上的準備。通過召開建模的頭腦風暴會議，討論系統(tǒng)的功能特征，并思考實現(xiàn)這些特征的高層設(shè)計策略，從技術(shù)圖表、用戶交互流程圖、領(lǐng)域圖和變更流程圖四個方面建模。
敏捷方法和工具的準備。管理實踐上選擇 Scrum 方法，在技術(shù)實踐上可選擇單元測試、自動化回歸測試，還有搭建 DevOps 流水線。
辦公環(huán)境設(shè)施的準備。如果項目中有人員是遠程的，則需要準備必要的音視頻設(shè)備，遠程會議工具；如果項目都在一個區(qū)域，就還要有適用于敏捷開發(fā)的辦公環(huán)境，如物理看板和開放式的工位等等。
05 | 試點推進過程
重組后的團隊還不是一支無往不勝的團隊，我們需要想辦法喚醒、激發(fā)團隊，讓整個團隊更有活力和戰(zhàn)斗力。
一起制定社會契約
為了讓團隊成員加強協(xié)作、發(fā)揮價值，一起約定的基本準則。工作中，若有人的行為影響了團隊協(xié)作，其他成員都可以拿出這個契約來約束他，從而做到“對事不對人”。
制定的過程：分發(fā)貼紙，靜默5分鐘，思考：“你認為加強協(xié)作、達成團隊目標，需要哪些行為準則？”。一張貼紙只寫一條準則，寫好準則的貼紙貼到白板上；白板劃分為不同區(qū)域，把內(nèi)容相似的貼紙歸在同一個區(qū)域。逐條讀貼紙上的準則，詢問大家是否同意，如果有人不同意，就停下來討論，如果討論的結(jié)果還是有人不同意，就放棄它；如果大家都同意，就將該準則保留下來。
落實契約。“社會契約”要張貼到所有團隊成員都可以看到的地方，以便整個團隊時時可以看到它，感受它帶來的激勵和約束。
回顧會議，引導(dǎo)團隊的自主性
先說明會議目的：“檢查調(diào)整”。接著討論：團隊工作中做得好的地方是什么？做得不好的地方又是什么？除此之外，有沒有什么其它疑問？
分發(fā)貼紙，靜默5分鐘。一張貼紙只寫一條，寫好的貼紙貼到白板上；白板劃分為不同區(qū)域，把內(nèi)容相似的貼紙歸在同一個區(qū)域。接著討論這些問題，做得好的地方就可以保持下去，做得不好的地方可以頭腦風暴去改善，并做一些行動計劃。
會議時間不能超過90分鐘。
成績墻與錯題集，記錄團隊敏捷的成長
06 | 規(guī)模化推廣
規(guī)模化推廣≠直接復(fù)制試點經(jīng)驗
一、兩個框架
SaFe（Scaled Agile Framework）和 LeSS（Large Scale Scrum）。要想做好敏捷的規(guī)模化推廣，不要套用框架，也不要被框架限制，只要它們的可取之處能幫到我們，我們就可以有選擇地拿來使用。
二、如何做規(guī)模化推廣
從痛點切入，再從以下五方面規(guī)模化推廣敏捷：
1. 選擇合適的規(guī)模化推廣策略。推廣時該選擇激進式變革還是漸進式改革？這兩種策略沒有優(yōu)劣之分，你需要結(jié)合企業(yè)變革的急迫程度、領(lǐng)導(dǎo)支持敏捷推廣的力度以及團隊能接受的方式來進行選擇。
2. 做好敏捷文化鋪墊，培養(yǎng)好敏捷的中堅力量。要做好必要的全員敏捷基礎(chǔ)培訓(xùn)和核心敏捷人員的能力培養(yǎng)。
3. 搭建適合敏捷的工作環(huán)境，做好必要的工具和自動化準備。適合敏捷的工位布置，必要的物理白板和各種協(xié)同管理工具等。
4. 組織級別的敏捷度量以及持續(xù)改進。你要做好組織級別的敏捷度量，從效率、質(zhì)量、成本等方面收集敏捷相關(guān)的數(shù)據(jù)，并借由這些數(shù)據(jù)輔助企業(yè)做持續(xù)改進。
5. 重視大型團隊的敏捷導(dǎo)入與推廣。這一點是規(guī)模化敏捷的核心，因為有的產(chǎn)品需要多個團隊共同交付一個產(chǎn)品，這就涉及到復(fù)雜的團隊間的敏捷。
三、大型團隊敏捷的導(dǎo)入和推廣
1. 可能遇到的問題：敏捷走到業(yè)務(wù)那里就卡殼，業(yè)務(wù)人員參與度低；跨團隊溝通不暢，協(xié)作效率低。大型團隊敏捷的導(dǎo)入和推廣，首先要打造端到端的、從需求到開發(fā)到測試到運維到運營的敏捷全生命周期，向業(yè)務(wù)敏捷靠攏。
2. 定制度。確立產(chǎn)品負責人制度，將以“項目”為中心的管理改為以“產(chǎn)品”為中心的管理。
3. 定反饋機制。在整個產(chǎn)品研發(fā)流程中進行數(shù)據(jù)收集和處理，做到從業(yè)務(wù)創(chuàng)意和機會捕捉到需求識別，到開發(fā)上線，再到業(yè)務(wù)運營的整體大反饋閉環(huán)。
4. 建立各團隊間的敏捷實踐，就需要提前安排支持工作。這樣，你們團隊需要協(xié)助的工作就會被排入對方的工作列表，就更加易于團隊間依賴關(guān)系的管理。
07 | 填坑
坑一：團隊說他們不想做敏捷
原因：
1.團隊沒有真正理解到底什么是敏捷、敏捷能給他們帶來什么切實有效的幫助；
2.團隊真的很忙（當然“忙”要分情況應(yīng)對，是否是有效的忙碌也是一個值得探討和挖掘的方面）；
3.團隊中有人一言堂，這個人的意見不改變，其他人不敢動。
解決：
不了解和分析現(xiàn)狀就直接推進敏捷是非常不靠譜的，必須看清現(xiàn)實，摸清項目的痛點，在解決痛點的基礎(chǔ)上導(dǎo)入并推進敏捷才是可行的。
坑二：不理解敏捷實踐背后的意義，把敏捷當作一種新的流程，而忘記敏捷的核心是持續(xù)改進
原因：
1.公司敏捷實踐的基礎(chǔ)導(dǎo)入工作沒有做好，連敏捷究竟是什么，以及為什么要做敏捷都沒給團隊講清楚；
2.缺乏一名強有力的敏捷教練做引導(dǎo)，在持續(xù)改進方面欠缺較大。
解決：
基礎(chǔ)培訓(xùn)；找一個靠譜的敏捷教練陪伴。
坑三：Scrum 過程被嚴重縮減，只剩下每日站會
原因：
沒有培養(yǎng)出屬于自己的合格的 Scrum Master。導(dǎo)致敏捷教練或scrum master撤出后，敏捷的火種無人守候，敏捷隨之偃旗息鼓。
解決：
1.要認識到 Scrum Master 的重要性。團隊還不成熟的時候，他負責宣講敏捷的價值觀、理念，也負責具體實踐的導(dǎo)入和守護。好的 Scrum Master 在引導(dǎo)、教育、輔導(dǎo)、教練這四個方面都有很強的能力，并能根據(jù)具體的情景選擇使用哪種能力來幫助團隊體驗敏捷帶來的益處，堅定維持團隊新養(yǎng)成的敏捷習慣。在領(lǐng)導(dǎo)力方面，他具有服務(wù)型領(lǐng)導(dǎo)的理念，是團隊的主心骨，在構(gòu)建敏捷文化等方面對推進敏捷具有很大的意義。
2.在基層留有敏捷的火種。在推進敏捷實踐之初，團隊就應(yīng)該計劃 Scrum Master 的培養(yǎng)活動，識別出優(yōu)秀的 Scrum Master，然后相互配合著推進敏捷；每周舉辦 Scrum Master 工作研討會，讓 Scrum Master 學(xué)習和實踐上文講的 4 種能力。在敏捷實踐后期，由 Scrum Master 來負責進行團隊引導(dǎo)等工作，并聽取敏捷教練的反饋意見，這樣在敏捷教練離開之后，培養(yǎng)好的 Scrum Master 就會接過敏捷的大旗，專心引導(dǎo)和輔導(dǎo)團隊，在團隊遇到困難時及時幫助解決。
坑四：筒倉中的敏捷
筒倉指的是部門各自為政，不好協(xié)同。
可能遇到的問題：
1.產(chǎn)品業(yè)務(wù)部門沒有協(xié)同，因此對需求的分析理解還是極其緩慢，每次到迭代開始時，需求都準備不好，打亂開發(fā)的節(jié)奏；
2.上線運維部門也與開發(fā)測試部門割裂，導(dǎo)致雖然開發(fā)測試做得很快，然而到了上線那一步又變慢了，最終拖慢了整個進程。
解決：
1.前期應(yīng)該多宣講敏捷的本質(zhì)和好處，尤其應(yīng)該推動對高管層面的宣講，并成立更高級別的敏捷實踐督導(dǎo)團隊。當高管層面理解到敏捷的好處和他們應(yīng)該做的事情之后，就不會成為推進敏捷的桎梏，而能及時為敏捷提供必要的幫助。
2.推進敏捷時要通盤考慮整個鏈條應(yīng)該怎么推進。
3.敏捷可以分步推進，但是推進過程中一旦識別出新的阻礙，應(yīng)及時去除。
08 | 如何防止敏捷變?yōu)樾∑俨?/h2>
小瀑布
大項目或需求做一個模塊拆分，然后一個一個模塊做下去，和瀑布模式相比，這種方式有了一點進步。然而，究其本質(zhì)，仍然還是瀑布，我們一般稱它為“小瀑布”。
真正的敏捷
團隊會盡可能有效拆分需求，進入到迭代內(nèi)的需求是多個獨立的小需求。小到每個需求都可以在很短的時間內(nèi)，比如 2～3 天內(nèi)完成開發(fā)和測試，最長也不要超過一個迭代周期。
這樣在開發(fā)人員寫代碼的時候，測試人員在寫測試案例，或者在考慮使用自動化測試方案。由于需求拆分得足夠小，很可能第一個小需求在迭代后的第二天就可以交付測試了，在測試人員測試這個需求的同時，開發(fā)人員繼續(xù)開發(fā)下一個小需求，由此形成一個良好的循環(huán)。在這種情況下，大家都在熱火朝天地工作，節(jié)省了很多等待的時間。
避免敏捷做成“小瀑布”？
首先要給予團隊在敏捷知識上的宣貫，在使他們充分了解敏捷的基礎(chǔ)上，對他們進行技能上的培養(yǎng)。
其次，挑選好并先從有價值的、優(yōu)先級最高的需求開始做。
在敏捷實踐中，我們工作的結(jié)束點不應(yīng)該是把之前所有計劃的工作做完，而是把客戶需要的工作做完。這些工作不一定是之前就被納入計劃的，但卻一定要是客戶最需要的。
需求拆分
需求拆分的方法有很多，例如按照業(yè)務(wù)流程、按照業(yè)務(wù)規(guī)則的變化或按照數(shù)據(jù)的處理方式進行拆分等等。不管是使用哪種拆分方法，做需求拆分的目的，都是把大需求拆成一個個能夠獨立開發(fā)測試的小需求。只有這樣，我們才能在迭代中同時做幾個小需求，而不需要等待，并且在測試完成后，這些小需求也能獨立上線。
若需求經(jīng)過拆分后還是很大，無法在 2 周內(nèi)做完，這種情況怎么辦呢？這時就需要深度的挖掘一下背后的原因，采用相應(yīng)的應(yīng)對策略。如系統(tǒng)架構(gòu)比較老舊，代碼的耦合度較高，依賴性大，要完成一個需求甚至要改很多個系統(tǒng)，這對于產(chǎn)品交付來說明顯是一個很大的障礙。
如遇以上問題，可在開發(fā)測試工作之余，對該產(chǎn)品進行架構(gòu)演化，拆分微服務(wù)。為了能順利開展這些工作，團隊用 70% 的時間進行新需求的開發(fā)，用 30% 的時間進行架構(gòu)演進。
08 | 參考資料
網(wǎng)絡(luò)資源：scrum中文網(wǎng)
書單：《敏捷革命》《用戶故事與敏捷方法》《敏捷教練：如何打造優(yōu)秀的敏捷團隊》《敏捷軟件開發(fā)：原則、模式與實踐》《scrum敏捷項目管理》《硝煙中的scrum和xp》《敏捷回顧：團隊從優(yōu)秀到卓越之道》《團隊協(xié)作的五大障礙》《持續(xù)集成》《持續(xù)交付》《Devops實踐》《有效的單元測試》《測試驅(qū)動開發(fā)》《重構(gòu)》《代碼整潔之道》
