《說透敏捷》是極客時間上的付費課程，里面有很多案例辟躏，如果想學(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)》《代碼整潔之道》
