軟件開發(fā)-在瀑布式項目中實現(xiàn)敏捷開發(fā)

1、在瀑布式項目中實現(xiàn)敏捷開發(fā)盡管一個大型項目整體很好地遵循著一個瀑布模型，但該項目的應(yīng)用程序開發(fā)團隊希望改用敏捷開發(fā)。開發(fā)人員曾討論過要讓項目全面地改用敏捷模型，但最終決定只使敏捷開發(fā)作為項目的一部分、適當(dāng)?shù)厝谌氲秸w瀑布式結(jié)構(gòu)中。最后，該團隊實現(xiàn)了更優(yōu)異的質(zhì)量、更多可交付成果以及更高的開發(fā)效率。這一成功使得他們在整個項目范圍內(nèi)提倡敏捷理念，并且得到越來越多的支持，最終讓所有參與團隊都信任敏捷開發(fā)。 本文來自于 IBM WebSphere Developer Technical Journal。Liz Hines, 程序主管, IBMScott Baldwin, ScrumMaster

2、 和軟件工程師, IBMMark Giles, 開發(fā)經(jīng)理, IBMJuan Peralta, 開發(fā)項目經(jīng)理, IBM2009 年 9 月 24 日簡介瀑布式項目方法在許多組織中都確立了十分牢固的地位，于是編寫代碼的開發(fā)團隊通常沒有權(quán)力做出 “遷移到敏捷流程” 這一決策。在涉及到數(shù)個組織的大型項目中，情況尤是如此。雖然已有提議讓最近的一個重點項目采用敏捷開發(fā)，但在負責(zé)項目中關(guān)鍵應(yīng)用程序之一的開發(fā)團隊沒有決定更進一步、將敏捷方法應(yīng)用到他們所控制的那部分項目中之前，這些提議沒能得到進展。采用敏捷開發(fā)這一決策所產(chǎn)生的成果證明了敏捷開發(fā)的價值和益處，更重要的項目管理團隊在整體項目環(huán)境中可理解并欣賞這種價

3、值和益處。本文介紹了開發(fā)團隊如何在較大型的瀑布式項目中成功地實現(xiàn)敏捷開發(fā)。本示例包含所執(zhí)行的概念和技巧、所面臨的挑戰(zhàn)以及所產(chǎn)生的益處，可幫助您尋找到類似的有用方法，利用這種方法您可將敏捷概念和流程介紹到您的組織中。本文假定您熟悉基本項目管理、敏捷開發(fā)概念和術(shù)語。項目背景作為本案例研究之對象的特定應(yīng)用程序，是一款現(xiàn)有的由一個全球銷售團隊使用的銷售合同應(yīng)用程序。此應(yīng)用程序已面世數(shù)年，通常每年都發(fā)布 3 到 4 個主要或次要版本。此應(yīng)用程序的客戶群很大而且多樣化，包括 3,000 名超級用戶，以及數(shù)千名臨時用戶。這一正在進行中的項目由 CIO 辦公室管理，解決方案領(lǐng)導(dǎo)代表了客戶。項目團隊整體中的各種

4、成員 用戶、設(shè)計師、架構(gòu)師、開發(fā)人員、測試人員、生產(chǎn)操作人員等等 來自公司內(nèi)的不同組織。此瀑布式項目的整合開發(fā)流程包含以下階段：· 制定概念前· 制定概念· 計劃· 開發(fā)· 驗證· 首次展示在制定概念前階段，開發(fā)團隊提供粗數(shù)量級 (ROM) 的提議發(fā)布內(nèi)容和（未確定的）目標日期。在制定概念階段，客戶為所發(fā)布內(nèi)容的候選列表排列優(yōu)先級，創(chuàng)建并審查業(yè)務(wù)需求和系統(tǒng)需求，開發(fā)團隊還提供業(yè)務(wù)需求 (BR) 和系統(tǒng)需求的 (SR) 的影響等級 (LOE)。在計劃階段，SR 候選列表會確定，而且開發(fā)團隊會對這些需求確立初步的規(guī)模估計。對此項目而言，典

5、型的計劃如下所示：· 制定概念階段：2 個月· 計劃階段：2 個月· 開發(fā)階段：6 周· 驗證階段：6 周在這些階段（甚至是為期 6 周的開發(fā)階段）中，客戶要求 (CWN)、BR、SR 以及最后的更改請求的候選列表將持續(xù)更新并重新劃分優(yōu)先級。就應(yīng)用程序中所使用的技術(shù)而論，它構(gòu)建于一個面向服務(wù)架構(gòu) (SOA) 平臺之上，利用了 IBM® WebSphere® Process Server V6.0.2.4、IBM WebSphere Portal V6.1 和 IBM DB2® 9.1.6 的高可用性功能。該應(yīng)用程序利用 We

6、b 服務(wù)以與公司內(nèi)部其他應(yīng)用程序相整合。此外，利用了 WebSphere Process Server 技術(shù)來管理業(yè)務(wù)規(guī)則和過程工作流。與其他內(nèi)部應(yīng)用程序的需求和版本發(fā)布計劃相協(xié)調(diào)，可降低項目應(yīng)用程序版本發(fā)布的規(guī)劃和安排的復(fù)雜性。為什么要使瀑布式項目變得敏捷？此應(yīng)用程序每次發(fā)布典型版本，都將大量時間（長達 7 個月的周期中的 4 個月）消耗在制定概念和計劃階段。盡管這樣，需求依然會變化。開發(fā)團隊決定尋求一種敏捷方法，因為敏捷方法可適應(yīng)業(yè)務(wù)優(yōu)先級和需求的變化，并在項目進展時適應(yīng)開發(fā)重構(gòu)。這種方法將使開發(fā)團隊能夠減少制定概念和計劃階段的大量時間，將更多時間用于開發(fā)階段，并且將重點放在交付更多功能和

7、更高質(zhì)量上。由于部署窗口和參與驗收測試的有效用戶是有限的，所以部署日期也受到限制，而且通常在制定概念階段早期就確定了。冗長的計劃和再計劃通常導(dǎo)致開發(fā)階段縮短，于是開發(fā)階段會持續(xù)混亂并必然延遲。在開發(fā)階段頻繁改變發(fā)布優(yōu)先級并不會起到幫助作用。開發(fā)團隊的一個主要目標是采用更好的開發(fā)流程，來控制因外部影響（后期需求、不斷變化的需求等）和自有的不良流程（不完全的開發(fā)流程、低下的代碼質(zhì)量等）而引起的混亂。采用敏捷方法可改變他們的開發(fā)文化，使其獲得流程的控制權(quán)。除此之外，開發(fā)團隊還意識到敏捷方法的其他益處：更佳的質(zhì)量、更快的實現(xiàn)以及更高的客戶滿意度。他們還相信，如果他們能夠推進敏捷流程，他們將有動力說服更

8、大的項目整體改用敏捷方法。他們獲得的教訓(xùn)幫助他們制作出其工具和流程的任何操作指南，并加快向敏捷流程的最終轉(zhuǎn)變。敏捷方法真正實現(xiàn)的程度如何？粗體術(shù)語是 Scrum Framework 中已定義的元素。請訪問 ScrumAlliance Web 站點了解詳情。在項目最初開始時，開發(fā)團隊嘗試了采用一些（而不是全部）Scrum 框架 的概念，Scrum 框架是一種基于經(jīng)驗流程控制理論的敏捷流程，它關(guān)注透明度、審查以及適應(yīng)。該團隊實現(xiàn)了日常站立短會和 burndown 圖表，但選擇不采用組件來支持審查，例如 sprint 計劃、sprint 審

9、查和回顧會議 (retrospective meeting)。當(dāng)項目進展到瀑布驗證階段 在此階段中開發(fā)團隊需要處理持續(xù)的一串流程來測試缺陷 團隊的 scrum 流程就結(jié)束了。當(dāng)下一版本的開發(fā)階段開始時，他們必須再次啟動 scrum 流程。從根本上講，初次嘗試 Scrum 而失敗是沒有采用審查流程的結(jié)果；這一教訓(xùn)在之后的 Scrum 工作中對團隊起到了幫助作用。在更近期版本的開發(fā)階段，開發(fā)團隊決定改弦更張，引入以 Scrum 概念和特征為基礎(chǔ)的完整敏捷流程。該團隊堅決進行 sprint 計劃、sprint 審查和回顧會議。更重要的是，他們致力于執(zhí)行審查與自我治理。· 角色為全面采用 S

10、crum 工作方式，團隊必須確定 scrum 團隊中的哪些成員將擔(dān)任 3 個必要角色，即產(chǎn)品負責(zé)人 (Product Owner)、項目經(jīng)理 (ScrumMaster) 和 團隊 (Team)。最初，開發(fā)項目經(jīng)理擔(dān)當(dāng)主要產(chǎn)品負責(zé)人的身份。該團隊由現(xiàn)有開發(fā)團隊成員組成。被選定的 ScrumMaster 確立了周期為 3 到 4 周的 sprint 日程表， 以及不一定要與瀑布流程里程碑一致的起止日期；團隊認識到，計劃中的 sprint 會議與瀑布里程碑太近，會導(dǎo)致團隊重心轉(zhuǎn)移到兩個事件之一之上，而不能兼顧，那么被忽視的事件會產(chǎn)生不利的結(jié)果。· 待辦事項在 sprin

11、t 計劃會議上，開發(fā)團隊首先要討論的是，客戶（在制定概念和計劃階段）已針對應(yīng)用程序未來版本而鑒定出的候選產(chǎn)品待辦事項。產(chǎn)品負責(zé)人挑選出這些項目的一個子集，包含考慮在 sprint 中解決的可能產(chǎn)品待辦事項。在 sprint 計劃會議中，開發(fā)團隊研究他們相信自己可在 sprint 中完成的產(chǎn)品待辦事項，從中整理出 sprint 待辦事項。這些待辦事項就是團隊要在 sprint 過程中實際處理的任務(wù)、任務(wù)評估和分配。· 審查在每個 sprint 的末尾，開發(fā)團隊要舉行一個 sprint 審查會議。此會議的目的是向 stakeholders 

12、;說明 sprint 中的成果，并為涉眾提供適時的機會來評論和提問，這可能生成一份期望修改列表。這些修改和任何缺失的或錯誤的功能都添加到下一次 sprint 的產(chǎn)品待辦事項中。· 回顧在每個 sprint 的末尾，開發(fā)團隊還要舉行一個 sprint 回顧會議，來回顧 sprint 中良好的部分和可以改進的部分?；诖朔答?，他們可以適當(dāng)修改流程，以及向產(chǎn)品待辦事項追加非功能性操作項。· 計劃典型的計劃是在 sprint 結(jié)束時的同一天舉行 sprint 審查和 sprint 回顧會議，接下來的第二天就舉行下一個 sprint 的 sprint 計劃會議。這些會議在

13、Scrum 時間盒指導(dǎo)方針下進行。· 參與者客戶代表 (解決方案領(lǐng)導(dǎo)者) 會參與 sprint 計劃和 sprint 審查會議。最初，客戶的利益由開發(fā)項目經(jīng)理代表，但在之后的 sprint 中，開發(fā)團隊能夠使解決方案領(lǐng)導(dǎo)者介入，通過這些關(guān)鍵參與者獲取直接的客戶輸入和反饋。這種方法目的很明顯；團隊希望良好地理解流程與方法，然后再擴大參與者圈子，讓解決方案領(lǐng)導(dǎo)者加入。· 用戶案例開發(fā)團隊還在計劃中采用了用戶。雖然客戶代表（解決方案領(lǐng)導(dǎo)者）應(yīng)當(dāng)負責(zé)創(chuàng)建用戶案例，但開發(fā)團隊根據(jù)現(xiàn)有需求為之代勞了，因為更大的項目尚未使用敏捷流程。然后該團隊讓解決方案領(lǐng)導(dǎo)者參與驗證用戶案例，合作改進案

14、例并更好地理解需求。這一實踐極大程度地改善了對需求的理解和需求的準確度，并且顯著減少了實行之后的返工。· 質(zhì)量保證開發(fā)團隊曾長期使用連續(xù)累計，但他們最近將自動測試引入到了開發(fā)流程中。直到自動測試可用并且融合到測試工具中，才能認為工作項是完整的。每日構(gòu)建和自動測試可確保在代碼簽入時不破壞編碼基數(shù)。這會生成高質(zhì)量代碼，并減少驗證階段中將發(fā)現(xiàn)的缺陷。直到功能可以在活動服務(wù)器上驗證，才能認為編碼項是完整的。例如新流程或文檔等非編碼項，發(fā)表在開發(fā)團隊的內(nèi)部 wiki 上，并分發(fā)給團隊，以便在完整呈現(xiàn)于 sprint 審查會議上之前先進行審查。其他敏捷元素因為開發(fā)團隊依照嚴格瀑布式流程而運作，所

15、以他們不能全方面采用敏捷開發(fā)。團隊仍然履行一個需求周期，以將 CWN 細化為 BR 和 SR、劃分優(yōu)先級、ROM、LOE 和初步規(guī)模估計、添加新需求，以及重復(fù)地循環(huán)。開發(fā)團隊能夠在需求周期中促成一些改進；例如，他們能夠處理由客戶代表核對過的優(yōu)先列表，能夠在需求周期中根據(jù)不同要點篩分用戶案例，從而構(gòu)建候選作用域列表以供客戶審查。團隊利用了 Scrum 流程來處理這種活動，針對需求周期生成了必要的工作產(chǎn)品，最終減少了開發(fā)階段可怕的需求混雜。如果項目完全改用敏捷流程，用戶案例有希望在周期之初就確立，優(yōu)先級的劃分有希望限于 1 或 2 個周期中完成，而且更多時間有希望用在開發(fā)階段。敏捷采用的這種狀態(tài)可

16、支持與客戶一起審查已實現(xiàn)的特性，并且根據(jù)客戶反饋來更新功能，而不是在文件上多次重新修改不同等級的需求。開發(fā)團隊沒有完全依靠 sprint 待辦事項和 burndown 圖表工具來分配和跟蹤工作，而是使用了一個傳統(tǒng)的 Microsoft® Project 計劃來在開發(fā)階段安排任務(wù)。這種做的理由有很多。首先，這向客戶證明了分配給此項目的資源已完全利用，交付了盡可能多的內(nèi)容。其次，Microsoft Project 是瀑布式項目中備受期待而且更受認可的狀態(tài)交流方式。然而，在更新狀態(tài)時除了項目計劃外還參考 burndown，開發(fā)團隊就采取了措施，使其他團隊接觸并過渡到敏捷跟蹤方法。應(yīng)對挑戰(zhàn)當(dāng)

17、然，以兩種內(nèi)在特性不同的項目管理風(fēng)格（和文化）來進行工作，會給開發(fā)團隊帶來諸多挑戰(zhàn)：· 語言從瀑布流程過渡到敏捷流程時，一個重要挑戰(zhàn)就是要銜接術(shù)語。在本項目中，開發(fā)項目經(jīng)理非常出色地進行了術(shù)語轉(zhuǎn)換，既同客戶以瀑布形式交流，又彌合了敏捷環(huán)境和瀑布環(huán)境中相對應(yīng)的工具和狀態(tài)之間的差異。借助這種適當(dāng)?shù)?“銜接”，開發(fā)團隊更加自由地采用自己的流程，并且采取了本文所述的循序漸進的步驟。· 計劃開發(fā)團隊的標準運作模式是持續(xù)執(zhí)行 sprint 周期 不管他們是否正特別處理一個候選發(fā)布版本。所以，sprint 包含了規(guī)模估計工作、生產(chǎn)支持活動以及驗證工作。因此，該團隊嘗試不使 sprint

18、在開發(fā)轉(zhuǎn)換里程碑 (DCUT) 之日啟動和中止。同樣，使 sprint 不在 DCUT 之日結(jié)束也很有用；在那個重要時期抽出兩天進行必要的會議，這不利于目標版本進入驗證階段。sprint 通常在 DCUT 之后的一周結(jié)束。· 支持最初，開發(fā)團隊努力在 sprint 中處理必然的產(chǎn)品支持。一些開發(fā)人員專門處理 3 級支持，但是出現(xiàn)的產(chǎn)品缺陷中多數(shù)需要整個開發(fā)團隊的成員來解決。盡管不能全面計劃所有這些工作，但是可預(yù)計一些與支持相關(guān)的常規(guī)工作。這種工作分兩部分執(zhí)行：分析和解決。有助于團隊將產(chǎn)品支持整合到 Scrum 模型之中的基本原則是，將任意產(chǎn)品缺陷的優(yōu)先級設(shè)為最高的可能值，于是初始分析

19、會優(yōu)先于開發(fā)人員手頭或者任務(wù)列表中的任意其他工作。在分析方面，當(dāng)產(chǎn)品缺陷生成時，通知單會添加到當(dāng)前 sprint，并根據(jù)嚴重性而分配。執(zhí)行根源分析，可確定提供解決方案要涉及的工作，而且此分析將找出問題的原因（或者，如果原因不明顯，則找出識別原因所必要的內(nèi)容），預(yù)估實現(xiàn)修復(fù)和創(chuàng)建單元測試的規(guī)模以及實現(xiàn)修復(fù)的困難度。一旦上述工作完成，通知單會從當(dāng)前 sprint 中移除，產(chǎn)品負責(zé)人會確定與產(chǎn)品待辦事項中其他項目相比的優(yōu)先級。根源分析預(yù)定要在現(xiàn)有服務(wù)水平協(xié)議 (Service Level Agreement) 需求的范圍內(nèi)執(zhí)行。然后產(chǎn)品負責(zé)人將問題分配到 sprint 待辦事項（可能是當(dāng)前 spri

20、nt 或者將來 sprint 的產(chǎn)品代辦事項），那么之后會通過一個發(fā)布版本、一個修復(fù)程序包或小修補程序而實現(xiàn)修復(fù)。開發(fā)團隊估計在部署新版本之后的兩周內(nèi)，每周會出現(xiàn) 10 個缺陷，如果進行過 4 小時的分析，則每周出現(xiàn) 3 個缺陷。· 更改產(chǎn)品問題會周期性地引發(fā)更改請求。開發(fā)團隊的指導(dǎo)方針指出，這些請求必須由產(chǎn)品負責(zé)人為之在 sprint 中劃分優(yōu)先級。如果產(chǎn)品負責(zé)人相信更改請求是開發(fā)團隊的最優(yōu)先事項，那么 ScrumMaster 和產(chǎn)品負責(zé)人要確定當(dāng)前 sprint 是否應(yīng)當(dāng)調(diào)整或（在罕見情況下）暫停，以適應(yīng)這些請求。· 轉(zhuǎn)換基礎(chǔ)架構(gòu)團隊是開發(fā)團隊的一個子集，他們負責(zé)編譯工

21、具、（測試和生產(chǎn)）服務(wù)器管理、數(shù)據(jù)庫管理等。此團隊分配在 sprint 之中，但他們也定期接收到來自項目中其他團隊的工作請求。這違背了 Scrum 的原則，該原則聲明團隊要單獨執(zhí)行其 sprint 工作。為緩解此問題，開發(fā)團隊利用了 3 個戰(zhàn)略：o 團隊識別出應(yīng)當(dāng)在每個 sprint 中都包含的基礎(chǔ)架構(gòu)任務(wù)，并將這些任務(wù)加入 sprint 待辦事項（例如，alpha 部署、beta 部署支持、產(chǎn)品在線備份等）。o 識別與產(chǎn)品待辦事項相關(guān)的任意基礎(chǔ)架構(gòu)任務(wù)，并將之加入 sprint 待辦事項。o 基礎(chǔ)架構(gòu)團隊領(lǐng)導(dǎo)被指定為外部技術(shù)架構(gòu)技能請求的焦點，與產(chǎn)品負責(zé)人合作確定這些工作項的優(yōu)先級，并根據(jù)需

22、要將工作項加入 sprint 待辦事項?；A(chǔ)架構(gòu)團隊成員了解到要拒絕這種干擾，于是遵從上述流程來處理這類請求。這使他們能全身心地繼續(xù)從事于 Scrum 流程。· 規(guī)模由于其規(guī)模，開發(fā)團隊最終會轉(zhuǎn)移為 Scrum 團隊的一個層次，劃分為 4 個團隊：o 業(yè)務(wù)流程/后端服務(wù)o 用戶界面o 生命周期管理o 基礎(chǔ)架構(gòu)這些團隊在內(nèi)部執(zhí)行每日 scrum。每兩周舉行一次 scrum 的 scrum，每個 Scrum 團隊有一名代表參加并總結(jié)最近一次會議以來他們團隊的狀態(tài)、下一次會議之前該團隊的計劃、任意現(xiàn)存障礙，以及他們會對其他 Scrum 團隊造成何種干擾。使用的工具開發(fā)團隊利用一個

23、 bug/問題跟蹤系統(tǒng)，該系統(tǒng)提供一個具有便利的報表程序的整合 Wiki。IBM Rational Team Concert 提供這種功能。團隊針對所有開發(fā)工作項創(chuàng)建跟蹤單，并為 sprint 生成（在其他報表之中的） burndown 圖表。團隊還能擴展工具和 Wiki 來適應(yīng)自身需求。例如，團隊可創(chuàng)建整合到 Wikipedia 之中的用戶案例工具。開發(fā)團隊大量利用開發(fā) Wiki 來記錄流程，提供對進度報表的訪問，以及接入其跟蹤系統(tǒng)。因為接入跟蹤系統(tǒng)，Wiki 是一種特別好的、用于文檔編制和協(xié)作的機制。開發(fā)團隊在 Microsoft Project 中構(gòu)建項目計劃。項目計劃引用了計

24、劃所包含的每個低級計劃的跟蹤單；這是在遷移到敏捷流程之前開始的演化。不是在相關(guān)時間內(nèi)引用一個 CWN，而是為在一個版本中交付 CWN 所涉及的每個任務(wù)創(chuàng)建跟蹤單。在可能的情況下，會細分任務(wù)，并將時間分配給兩個或更多開發(fā)人員，從而提高工作效率并減少整體編碼時間。細分出的每個任務(wù)都獲得自己的跟蹤單，并在項目計劃中單獨引用（目的是使每個任務(wù)單/任務(wù)最多只有一名所有者）。項目計劃也會為個體開發(fā)人員確定任務(wù)優(yōu)先級，還確定候選版本的整體優(yōu)先級。在跟蹤單上會創(chuàng)建一個自定義優(yōu)先級字段，此字段根據(jù)項目計劃而更新，并且按照開發(fā)人員執(zhí)行任務(wù)的正當(dāng)順序傳達給他們。實現(xiàn)的獲益正如預(yù)期和宣傳的那樣，采用敏捷流程的結(jié)果就是

25、提高了代碼質(zhì)量、加快了實現(xiàn)、提升了客戶滿意度，而且優(yōu)化了開發(fā)流程。開發(fā)團隊還獲得了其他益處，包括一些通常被認為和敏捷無關(guān)的益處：· 處理大型任務(wù)采用 Scrum 的重要益處之一就是，Srucm 使開發(fā)團隊能夠?qū)⒏邇r值項目加入版本中。這可能違反直覺；畢竟依照一些說法，限制在 2 周到 4 周之內(nèi)的 sprint 不能處理大型功能。在本項目中，大型特性很難填入到一個版本的優(yōu)先表中；比起一個大項目，客戶通常更愿意選擇 10 個較小的項目，即使那個大項目很重要。Scrum 強制開發(fā)團隊逐步重視這些大型特性，分解大型特性以進行分析或研究，然后增量式地實現(xiàn)。團隊能夠在與開發(fā)階段無關(guān)的 sprin

26、t 中良好地分析或研究，根據(jù)要求完成前置任務(wù)，然后更易于將增量實現(xiàn)加入到版本優(yōu)先事項中。這種方法也適用于非功能性項目，例如代碼重構(gòu)和自動化整合測試。很難讓客戶相信這種工作很重要，但是開發(fā)團隊能夠?qū)⒅貥?gòu)工作打散成小塊，構(gòu)建一個漸進的變更計劃，然后在 sprint 和版本中實現(xiàn)增量式變更。· 靈活性與此相關(guān)的益處是，可獲得解構(gòu)大型任務(wù)的能力和規(guī)程；sprints 強制開發(fā)團隊以對待較小規(guī)模任務(wù)的方式思考。對于較小的任務(wù)，團隊能更好地計劃版本內(nèi)容，還能在任務(wù)發(fā)生意外的情況下重新分配資源。大型任務(wù)往往需要更廣泛的技能和專業(yè)知識，但是分解成小任務(wù)之后，很多都能分配給技能范圍較窄的開發(fā)人員，這就

27、提高了資源分配的靈活性。在數(shù)個版本和多個 sprint 計劃會議之后，這種 “小任務(wù)” 理念就能在整個團隊的頭腦中生根了。· 流程改進Scrum 流程還提供了一個框架，以實現(xiàn)開發(fā)團隊之前所缺乏的增量流程改進。Sprint 回顧會議提供了有用的反饋，而且流程更改添加給下一個 sprint。在一些情況下，例如在生產(chǎn)支持和基礎(chǔ)架構(gòu)團隊的任務(wù)中，需要數(shù)個 sprint 來細化流程從而鑄造成功。團隊忠實于流程，解決了問題，并構(gòu)建了很好地為團隊工作的流程。· 處理更改開發(fā)團隊能更好地處理變更，即使是在 sprint 中期。在一個版本發(fā)布過程中，他們攜著對優(yōu)先事項的清晰理解，開始了開發(fā)階段；然后在一個 sprint 的中期，客戶帶來了全新的最優(yōu)先事項。通常這種混雜會挫傷團隊士氣，但他們利用了 Scrum 原則來討論可選項（中斷 sprint 并重新開始，或者繼續(xù)遵從不正確的優(yōu)先級列表）。因為開發(fā)團隊被授權(quán)制定決策，所以他們能夠改變方式，接受全新的優(yōu)先級，以獲得成功。· 工作環(huán)境Scrum 流程的采用對團隊士氣、團隊紀律以及團隊互動具有重大的影響。因為開發(fā)團隊被授權(quán)改進自己的流