第3章 敏捷開發(fā)

1、 第三章第三章 敏捷軟件開發(fā)敏捷軟件開發(fā)1Chapter 3 Agile software development本章的目標(biāo)是介紹敏捷軟件開發(fā)的幾種方法本章的目標(biāo)是介紹敏捷軟件開發(fā)的幾種方法1.1. 理解敏捷軟件開發(fā)的基本原理，敏捷方法的內(nèi)涵，以及和其它理解敏捷軟件開發(fā)的基本原理，敏捷方法的內(nèi)涵，以及和其它軟件開發(fā)方法之間的差別；軟件開發(fā)方法之間的差別；2.2. 了解極限編程的主要做法，以及它是如何貫徹和遵循敏捷軟件了解極限編程的主要做法，以及它是如何貫徹和遵循敏捷軟件開發(fā)方法的一般性的原理的；開發(fā)方法的一般性的原理的；3.3. 理解敏捷項目管理的理解敏捷項目管理的ScrumScrum方法；方

2、法；4.4. 了解在大型軟件項目開發(fā)過程中應(yīng)用可伸縮敏捷方法時的事項了解在大型軟件項目開發(fā)過程中應(yīng)用可伸縮敏捷方法時的事項和問題。和問題。Topics covered 敏捷軟件開發(fā)方法 Agile methods 計劃驅(qū)動和敏捷驅(qū)動 Plan-driven and agile development 極限編程 Extreme programming 敏捷項目管理 Agile project management 伸縮的敏捷開發(fā)方法Scaling agile methods3Chapter 3 Agile software development對軟件系統(tǒng)快速開發(fā)和交付經(jīng)常是最重要的需求對軟件系

3、統(tǒng)快速開發(fā)和交付經(jīng)常是最重要的需求 當(dāng)前業(yè)務(wù)都是處于一個全球性的、快速變化的環(huán)境中的。從市場、機遇、不斷變化的經(jīng)濟條件、出現(xiàn)新的競爭產(chǎn)品和服務(wù)等方面，要求軟件做出快速的開發(fā)；其次，用戶對軟件變更和新需求的要求，往往具有緊迫性，因此，對軟件系統(tǒng)快速開發(fā)和交付經(jīng)常是最重要的需求。4Chapter 3 Agile software development 如何才能快速開發(fā)軟件？快速軟件開發(fā)基本特征快速軟件開發(fā)基本特征 描述、設(shè)計、實現(xiàn)是項目交織在一起的 系統(tǒng)通過一系列版本開發(fā)出來。最終用戶和其他信息持有者參與對各個版本的評估。 用戶界面經(jīng)常用IDE工具快速完成。3.1 敏捷方法敏捷方法 敏捷方法是一

4、種從1990年代開始逐漸引起廣泛關(guān)注的一些新型軟件開發(fā)方法，是一種應(yīng)對快速變化的需求的一種軟件開發(fā)能力。簡單的說，敏捷開發(fā)是一種以人為核心、迭代、循序漸進的開發(fā)方法。在敏捷開發(fā)中，軟件項目的構(gòu)建被切分成多個子項目，各個子項目的成果都經(jīng)過測試，具備集成和可運行的特征。換言之，就是把一個大項目分為多個相互聯(lián)系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態(tài)。6Chapter 3 Agile software development敏捷宣言敏捷宣言 敏捷軟件開發(fā)宣言個體和交互個體和交互 勝過過程和工具勝過過程和工具工作的軟件工作的軟件 勝過詳盡的文檔勝過詳盡的文檔客戶合作客戶合

5、作 勝過合同談判勝過合同談判響應(yīng)變化響應(yīng)變化 勝過遵循計劃勝過遵循計劃也就是說，盡管右項有其價值，我們更重視左項的價值也就是說，盡管右項有其價值，我們更重視左項的價值Chapter 3 Agile software development7“敏捷宣言敏捷宣言”背后的背后的1212準(zhǔn)則（準(zhǔn)則（1 1）：）： 1. 我們的最高目標(biāo)是，通過盡早和持續(xù)地交付有價值的軟件來滿足客戶。 為客戶解決問題是軟件開發(fā)的最重要的目標(biāo)。 2. 歡迎對需求提出變更即使是在項目開發(fā)后期。要善于利用需求變更，幫助客戶獲得競爭優(yōu)勢。 問題可能隨時會變化，軟件開發(fā)是以問題提出者為中心解決問題提出者的問題，因此重要的是解決問題

6、而不是限制變化。 3. 要不斷交付可用的軟件，周期從幾周到幾個月不等，且越短越好。 檢驗適應(yīng)是敏捷問題解決方式的核心方式，不斷以客戶可檢驗的方式交付可用的軟件?！懊艚菪悦艚菪浴北澈蟮谋澈蟮?212準(zhǔn)則（準(zhǔn)則（2 2）：）： 4. 項目過程中，業(yè)務(wù)人員與開發(fā)人員必須在一起工作。 業(yè)務(wù)人員作為軟件開發(fā)的問題提出者，需要與軟件開發(fā)團隊（問題解決者）密切配合，促進問題解決 5. 要善于激勵項目人員，給他們以所需要的環(huán)境和支持，并相信他們能夠完成任務(wù)。 問題解決取決于人的投入程度與狀態(tài)，激勵項目人員，為他們創(chuàng)造環(huán)境和條件，能夠有助于問題的解決。 6. 無論是團隊內(nèi)還是團隊間，最有效的溝通方法是面對面

7、的交談。 敏捷問題解決方式推薦進行面對面的溝通與交流，這是人與人合作解決問題的最好溝通方式?！懊艚菪悦艚菪浴北澈蟮谋澈蟮?212準(zhǔn)則（準(zhǔn)則（3 3）：）： 7. 可用的軟件是衡量進度的主要指標(biāo)。 只以單位問題的解決結(jié)果也就是完成作為進度衡量的指標(biāo) 8. 敏捷過程提倡可持續(xù)的開發(fā)。項目方、開發(fā)人員和用戶應(yīng)該能夠保持恒久穩(wěn)定的進展速度。 在敏捷問題解決方式中，良好設(shè)計的迭代與穩(wěn)定的迭代進度是最有效的和最可預(yù)測的問題解決方式。 問題提出者與問題解決者所組成的團隊是解決問題的最佳組合，發(fā)揮團隊的力量解決問題遠勝于不明情況的指手劃腳。 9. 對技術(shù)的精益求精以及對設(shè)計的不斷完善將提升敏捷性。 不斷追

8、求更高效的解決問題，技術(shù)與設(shè)計是解決軟件問題的重要手段?！懊艚菪悦艚菪浴北澈蟮谋澈蟮?212準(zhǔn)則（準(zhǔn)則（4 4）：）： 10. 要做到簡潔，即盡最大可能減少不必要的工作。這是一門藝術(shù)。 問題的解決不取決于解決方案的復(fù)雜性，而是源自于對問題提出者和問題本身的深刻理解。當(dāng)然，問題解決方式本身也是重要的。 11.最佳的架構(gòu)、需求和設(shè)計出自于自組織的團隊。 團隊成員共同解決項目中所有問題 12.團隊要定期反省如何能夠做到更有效，并相應(yīng)地調(diào)整團隊的行為。 檢驗適應(yīng)是敏捷問題解決方式的核心。敏捷方法的基本原敏捷方法的基本原則則 原原則則描述描述客客戶戶參與參與 客客戶應(yīng)該戶應(yīng)該在開在開發(fā)過發(fā)過程中始程

9、中始終緊終緊密參與其中，他密參與其中，他們們的的作用是提供新系作用是提供新系統(tǒng)統(tǒng)的需求，的需求，對對需求排序，并需求排序，并評評估系估系統(tǒng)統(tǒng)的迭代。的迭代。增量式交付增量式交付 軟軟件以增量的形式開件以增量的形式開發(fā)發(fā)，客，客戶戶指定在每個增量中包指定在每個增量中包含的需求。含的需求。人非人非過過程程團隊團隊開開發(fā)發(fā)的技巧的技巧應(yīng)該應(yīng)該被承被承認認和和發(fā)揚發(fā)揚，保持他，保持他們們各自各自的工作的工作風(fēng)風(fēng)格，不落俗套。格，不落俗套。接受接受變變更更預(yù)預(yù)料系料系統(tǒng)統(tǒng)需求的需求的變變更，并更，并設(shè)計設(shè)計系系統(tǒng)統(tǒng)使之適使之適應(yīng)這應(yīng)這些些變變更更保持保持簡單簡單性性 關(guān)注關(guān)注軟軟件開件開發(fā)發(fā)和和軟軟件件

10、過過程的程的簡潔簡潔性，無性，無論論如何，如何，積積極地消除系極地消除系統(tǒng)統(tǒng)中的復(fù)中的復(fù)雜雜性。性。 12Chapter 3 Agile software development敏捷方法的適應(yīng)性敏捷方法的適應(yīng)性 以下情況適合于采用敏捷方法進行軟件開發(fā)： （1）軟件公司正在開發(fā)準(zhǔn)備出售的小項目或中等規(guī)模的項目 （2）屬于機構(gòu)內(nèi)部定制系統(tǒng)的開發(fā)，客戶有一個參與開發(fā)的明確的承諾，且沒有太多的來自外部的規(guī)則和法律的影響。因為它致力于小型的、緊密結(jié)合的團隊，將它擴展到大型系統(tǒng)的開發(fā)中會有很多問題。Chapter 3 Agile software development13敏捷方法的適應(yīng)性敏捷方法的適應(yīng)性

11、 敏捷方法適用于需求不確定并且快速改變的情況，如果系統(tǒng)有比較高的關(guān)鍵性、可靠性、安全性方面的要求，則可能不完全適合；敏捷方法在實踐中的問題 客戶可能很難保證全程參與到項目的開發(fā)中。 團隊成員可能不適應(yīng)高強度的投入。而這又是敏捷方法的特征。 在不同信息持有者之間，需求的優(yōu)先級變更困難。 維護簡單性需要額為的工作。 公司不適應(yīng)新系統(tǒng)帶來的工作變更。 當(dāng)產(chǎn)品出現(xiàn)問題時，容易出現(xiàn)互相推諉的情況。15Chapter 3 Agile software development敏捷方法和敏捷方法和軟軟件件維護維護兩個問題： 由于開發(fā)過程強調(diào)正式文檔的最小化，用敏捷方法開發(fā)系統(tǒng)是否具有可維護性？ 敏捷方法是否能

12、夠有效用于系統(tǒng)進化，以響應(yīng)系統(tǒng)變更的需求？Chapter 3 Agile software development16敏捷開發(fā)和系統(tǒng)具有較好的維護性是一對矛盾。敏捷開發(fā)和系統(tǒng)具有較好的維護性是一對矛盾。增量交付，面向變更的維護可能遇到的問題就是增量交付，面向變更的維護可能遇到的問題就是保持用戶的持續(xù)參與和開發(fā)團隊的持續(xù)性。保持用戶的持續(xù)參與和開發(fā)團隊的持續(xù)性。在系統(tǒng)維護上，關(guān)鍵是在系統(tǒng)維護上，關(guān)鍵是需求文檔需求文檔！3.2 3.2 計劃驅(qū)動和敏捷開發(fā)計劃驅(qū)動和敏捷開發(fā) 計劃驅(qū)動計劃驅(qū)動開發(fā)起源于系統(tǒng)工程和質(zhì)量規(guī)范，建立系統(tǒng)計劃驅(qū)動開發(fā)起源于系統(tǒng)工程和質(zhì)量規(guī)范，建立系統(tǒng)工程的原則，協(xié)調(diào)大量需要精

13、確協(xié)同工作的組件。通過從工程的原則，協(xié)調(diào)大量需要精確協(xié)同工作的組件。通過從需求到已完成的代碼等一系列代表物來推動軟件開發(fā)的過需求到已完成的代碼等一系列代表物來推動軟件開發(fā)的過程，計劃驅(qū)動開發(fā)非常精確地依賴于明確的步驟。程，計劃驅(qū)動開發(fā)非常精確地依賴于明確的步驟。 敏捷驅(qū)動 敏捷開發(fā)的過程中需求分析、軟件設(shè)計、軟件開發(fā)過敏捷開發(fā)的過程中需求分析、軟件設(shè)計、軟件開發(fā)過程相互交織在一起。強調(diào)軟件開發(fā)的快速性和需求變化的程相互交織在一起。強調(diào)軟件開發(fā)的快速性和需求變化的快速適應(yīng)性。文檔的最小化。快速適應(yīng)性。文檔的最小化。17Chapter 3 Agile software development表表

14、1 1 敏捷開發(fā)、計劃驅(qū)動軟件開發(fā)比較敏捷開發(fā)、計劃驅(qū)動軟件開發(fā)比較有要求有要求無，少無，少1010系統(tǒng)是否受制于外部的法規(guī)？系統(tǒng)是否受制于外部的法規(guī)？需大量系統(tǒng)分析需大量系統(tǒng)分析一般一般9 9開發(fā)的系統(tǒng)是什么樣類型的？開發(fā)的系統(tǒng)是什么樣類型的？要求低要求低水平高水平高8 8開發(fā)團隊的設(shè)計人員和編碼人員的能力如何？開發(fā)團隊的設(shè)計人員和編碼人員的能力如何？有影響有影響無要求無要求7 7有沒有可能影響系統(tǒng)開發(fā)的文化問題？有沒有可能影響系統(tǒng)開發(fā)的文化問題？團隊分散，有軟團隊分散，有軟件外包件外包團隊之間開團隊之間開發(fā)發(fā)6 6 開發(fā)團隊是怎么組織的？開發(fā)團隊是怎么組織的？不依賴不依賴IDEIDE有好的

15、有好的IDEIDE5 5有什么樣的技術(shù)支持開發(fā)？有什么樣的技術(shù)支持開發(fā)？長周期長周期短周期短周期4 4預(yù)想的系統(tǒng)的壽命有多長？預(yù)想的系統(tǒng)的壽命有多長？大大小，且在同小，且在同一地點一地點3 3開發(fā)系統(tǒng)的規(guī)模有對大？開發(fā)系統(tǒng)的規(guī)模有對大？否否是是2 2增量交付策略，即軟件交付給用戶并快速的取得增量交付策略，即軟件交付給用戶并快速的取得反饋，切實么？反饋，切實么？是是否否1 1 系統(tǒng)開始前，非常詳細的描述和設(shè)計很重要嗎？系統(tǒng)開始前，非常詳細的描述和設(shè)計很重要嗎？計劃驅(qū)動計劃驅(qū)動敏捷方法敏捷方法問題問題 多數(shù)軟件的開發(fā)均可用計劃驅(qū)動和敏捷方法完成。選用何種方法，參見上一頁的內(nèi)容。敏捷方法是一種思想，

16、不是具體的實現(xiàn)過程。目前，列入敏捷方法的有10多種。目前列入敏捷方法目前列入敏捷方法 軟件開發(fā)之韻，Software Development Rhythms 敏捷數(shù)據(jù)庫技術(shù)，AD/Agile Database Techniques 敏捷建模，AM/Agile Modeling 自適應(yīng)軟件開發(fā)，ASD/Adaptive Software Development 水晶方法，Crystal 特性驅(qū)動開發(fā)，F(xiàn)DD/Feature Driven Development 動態(tài)系統(tǒng)開發(fā)方法，DSDM/Dynamic Systems Development Method 精益軟件開發(fā)，Lean Softwar

17、e Development AUP（Agile Unified Process） ScrumScrum XBreed 極限編程，極限編程，XP XP eXtremeeXtreme Programming Programming 探索性測試XP XP 方法對敏捷基本原理的支持方法對敏捷基本原理的支持 增量式開發(fā)是通過小的、頻繁的版本來支持的。 客戶的參與是采用全時雇傭到開發(fā)團隊的形式。 人、而不是過程，通過結(jié)對編程、對系統(tǒng)代碼的集體擁有、可持續(xù)的開發(fā)過程而無需超額的工作時間來運作的。 對變更的支持是通過經(jīng)常性的版本發(fā)布，、測試優(yōu)先開發(fā)、重構(gòu)以避免代碼退化以及連續(xù)的集成新功能來實現(xiàn)的。 對簡單性的

18、維護通過持續(xù)的重構(gòu)來改善代碼的質(zhì)量、使用簡單的設(shè)計以減少系統(tǒng)將來的變更方式來支持的。21Chapter 3 Agile software development極限極限編編程的版本循程的版本循環(huán)環(huán) 22Chapter 3 Agile software development極限極限編編程程實實踐踐 (1) 原則或?qū)嵺`原則或?qū)嵺`描述描述（1）增量式規(guī)劃需求記錄在腳本卡片上，包含在版本中的故事情節(jié)可以決定可用的時間和它們的相對優(yōu)先級。開發(fā)者將這些腳本分解為開發(fā)的“任務(wù)”（2）小版本發(fā)布首先開發(fā)一個小版本的能提供業(yè)務(wù)價值的有用的最小集合，不斷的增量式的開發(fā)和發(fā)布23Chapter 3 Agile s

19、oftware development極限編程實踐 (2)期待所有的開發(fā)人員能連續(xù)地對代碼重構(gòu)，只要是發(fā)現(xiàn)可能改善的代碼就去做，這樣能保持代碼簡單性和可維護性（5）重構(gòu)在功能本身實現(xiàn)之前，采用一個自動單元測試框架來編寫對此新功能的測試（4）測試優(yōu)先不追求太多，只滿足當(dāng)前需求設(shè)計的功能。（3）簡單設(shè)計極限極限編編程程實實踐踐(3) 開開發(fā)發(fā)人人員員成成對對工作，工作，檢查檢查彼此的工作并提供支持彼此的工作并提供支持圓滿圓滿完成任完成任務(wù)務(wù)集體所有制意味著每個人都集體所有制意味著每個人都對對所有的程式所有的程式碼負責(zé)碼負責(zé)； ；這這一點，反一點，反過過來又來又意味著每個人都可以更改程序意味著每個人

20、都可以更改程序碼碼的任意部分。集體所有制的一個主的任意部分。集體所有制的一個主要要優(yōu)勢優(yōu)勢是提升了開是提升了開發(fā)發(fā)程序的速度，因程序的速度，因為為一旦程式一旦程式碼碼中出中出現(xiàn)錯誤現(xiàn)錯誤，任，任何程序何程序設(shè)計師設(shè)計師都能修正它。都能修正它。25Chapter 3 Agile software development（6）結(jié)對編程結(jié)對編程（7）集體所有集體所有極限極限編編程程實實踐踐 (4)（8）連續(xù)集成）連續(xù)集成任務(wù)一完成，就集成到系統(tǒng)中。并進行單元測試任務(wù)一完成，就集成到系統(tǒng)中。并進行單元測試（ （9）可持）可持續(xù)續(xù)的的節(jié)節(jié)奏奏大量超時是不能接受的的，因為它的后果就是降低大量超時是不能接受

21、的的，因為它的后果就是降低代碼的質(zhì)量和平均生產(chǎn)率。代碼的質(zhì)量和平均生產(chǎn)率。（ （10）在）在場場客客戶戶在極限在極限編編程中，程中，“ “客客戶戶” ”并不是并不是為為系系統(tǒng)統(tǒng)付付帳帳的人，而是的人，而是真正使用真正使用該該系系統(tǒng)統(tǒng)的人。極限的人。極限編編程程認為認為客客戶應(yīng)該時戶應(yīng)該時刻刻在在現(xiàn)場現(xiàn)場解決解決問題問題。例如：在。例如：在團隊團隊開開發(fā)發(fā)一個一個財務(wù)財務(wù)管理系管理系統(tǒng)時統(tǒng)時，開，開發(fā)發(fā)小小組組內(nèi)內(nèi)應(yīng)應(yīng)包含一位包含一位財務(wù)財務(wù)管理人管理人員員。 。XPXP需求腳本制作（需求腳本制作（Requirements scenariosRequirements scenarios）1.在X

22、P中，由XP團隊成員中的客戶或用戶負責(zé)需求的確定；2.用戶將需求采用場景或者故事的形式表述；將需求腳本寫到卡片上，然后，開發(fā)人員將這些需求分解成軟件實現(xiàn)任務(wù)（記錄到任務(wù)卡上），這些待實現(xiàn)任務(wù)是成本和進度估計的基礎(chǔ)；3.基于需求優(yōu)先級和軟件實現(xiàn)的進度估計，客戶在下一個版本實施前，選擇好優(yōu)先級高的需求進行開發(fā)（選擇自己描述的場景或故事）。27Chapter 3 Agile software development開處方的腳本（開處方的腳本（P41 P41 圖圖3-5 ）28Chapter 3 Agile software development舉例：開處方的任務(wù)卡舉例：開處方的任務(wù)卡 （P42 P

23、42 圖圖3-6 ）29Chapter 3 Agile software developmentXPXP測試測試Xp中的測試的關(guān)鍵特性：1. 測試優(yōu)先開發(fā)；2. 來自腳本的增量式測試開發(fā)；3. 用戶參與測試開發(fā)；4. 自動測試系統(tǒng)的使用；Xp強調(diào)先寫測試程序，再寫代碼，測試超前于代碼的編寫。可以對任務(wù)卡設(shè)計測試的用例描述。測試測試案例：案例：劑劑量量檢測檢測描述（描述（P43 圖圖3-7） ） 31Chapter 3 Agile software development結(jié)對編結(jié)對編程程Pair programming 結(jié)對編程(Pair Programming)是一個編程模式(Programm

24、ing pattern)。兩個程序員并排坐在一臺電腦前，面對同一個顯示器，使用同一個鍵盤，同一個鼠標(biāo)一起工作。他們一起分析，一起設(shè)計，一起寫測試例子，一起編碼，一起單元測試，一起集成測試，一起寫文檔等?；旧纤械拈_發(fā)環(huán)節(jié)都一齊肩并肩地，平等地，互補地進行開發(fā)工作。 結(jié)對編程不是一個人簡單地看著另一個在做什么在卓有成效的配對工作里，這兩個合作伙伴常常工作在不同抽象層次，一個人關(guān)注的是為實現(xiàn)眼前目標(biāo)而編寫的代碼的細節(jié)，而另一個人考慮的是更大的前景和下一步要做的事情，這兩個人的角色頻繁進行更換。這是一項高強度的、嚴密的，且常常令人疲勞的活動，但是能夠創(chuàng)造出經(jīng)過深思熟慮的高質(zhì)量代碼。 Laurie

25、Williams &Steve Hayes 32Chapter 3 Agile software development結(jié)對編結(jié)對編程的好程的好處處1. 支持共同擁有軟件和共同對系統(tǒng)負責(zé)2. 擔(dān)當(dāng)了非正式的復(fù)查過程3. 有助于支持重構(gòu)Chapter 3 Agile software development333.4 敏捷敏捷項項目管理目管理 敏捷方法的倡導(dǎo)者經(jīng)常發(fā)現(xiàn)：在應(yīng)用開發(fā)中，對動態(tài)變更很難得到管理方面的支持。這些方法需要開發(fā)者、管理者和用戶都改變他們工作和思考的方式。例如，XP實踐中的結(jié)對編程、測試優(yōu)先的開發(fā)、持續(xù)集成以及在場客戶等是很難讓人接受的。而且，這些方法論更傾向于以開發(fā)者為中心

26、，似乎并不太重視管理角色。 實踐證明，加強管理是敏捷方法被成功采納并應(yīng)用的關(guān)鍵 而傳統(tǒng)項目管理方法學(xué)和工具與這些新的敏捷方法缺少關(guān)聯(lián)34Chapter 3 Agile software developmentScrumScrum是一個通用的敏捷方法，但它主要注重迭代開發(fā)的管理，而不是管理敏捷軟件工程的專門的技術(shù)方法。Chapter 3 Agile software development35Scrum 管理管理過過程程圖圖36Chapter 3 Agile software developmentScrum的三個階段：1 規(guī)劃綱要：建立大致的目標(biāo)，設(shè)計軟件體系結(jié)構(gòu)2 沖刺循環(huán)：每個循環(huán)開發(fā)出一

27、個增量3 項目結(jié)束階段總結(jié)項目：完善項目文檔，如系統(tǒng)幫助，用戶手冊，總結(jié)項目開發(fā)經(jīng)驗Scrum過過程程-沖刺循沖刺循環(huán)環(huán)在每一次沖刺（一個15到30天的周期，其長度由開發(fā)團隊決定）當(dāng)中，開發(fā)團隊創(chuàng)建可用的（可以隨時推出）軟件的一個增量。每一個沖刺所要實現(xiàn)的功能來自產(chǎn)品訂單（product backlog）。產(chǎn)品訂單是按照優(yōu)先級排列的要完成的工作的概要的需求，哪些訂單項會被加入一次沖刺將由沖刺計劃會議決定。 在會議中，產(chǎn)品負責(zé)人告訴開發(fā)團隊他需要完成產(chǎn)品訂單中的哪些訂單項。開發(fā)團隊決定在下一次沖刺中他們能夠承諾完成多少訂單項。在沖刺的過程中，沒有人能夠變更沖刺訂單（sprint backlog），這意味著在一個沖刺中需求是被凍結(jié)的。Scrum會會議議 在沖刺中，每一天都會舉行項目狀況會議，被稱為 “每日站立會議”，15min，內(nèi)容包括： 說明工作進度 遇到的問題 接下來一天的工作計劃 可可擴擴展的敏捷方法