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

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

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

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

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

5、型的計(jì)劃如下所示：· 制定概念階段：2 個(gè)月· 計(jì)劃階段：2 個(gè)月· 開(kāi)發(fā)階段：6 周· 驗(yàn)證階段：6 周在這些階段（甚至是為期 6 周的開(kāi)發(fā)階段）中，客戶(hù)要求 (CWN)、BR、SR 以及最后的更改請(qǐng)求的候選列表將持續(xù)更新并重新劃分優(yōu)先級(jí)。就應(yīng)用程序中所使用的技術(shù)而論，它構(gòu)建于一個(gè)面向服務(wù)架構(gòu) (SOA) 平臺(tái)之上，利用了 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ù)來(lái)管理業(yè)務(wù)規(guī)則和過(guò)程工作流。與其他內(nèi)部應(yīng)用程序的需求和版本發(fā)布計(jì)劃相協(xié)調(diào)，可降低項(xiàng)目應(yīng)用程序版本發(fā)布的規(guī)劃和安排的復(fù)雜性。為什么要使瀑布式項(xiàng)目變得敏捷？此應(yīng)用程序每次發(fā)布典型版本，都將大量時(shí)間（長(zhǎng)達(dá) 7 個(gè)月的周期中的 4 個(gè)月）消耗在制定概念和計(jì)劃階段。盡管這樣，需求依然會(huì)變化。開(kāi)發(fā)團(tuán)隊(duì)決定尋求一種敏捷方法，因?yàn)槊艚莘椒蛇m應(yīng)業(yè)務(wù)優(yōu)先級(jí)和需求的變化，并在項(xiàng)目進(jìn)展時(shí)適應(yīng)開(kāi)發(fā)重構(gòu)。這種方法將使開(kāi)發(fā)團(tuán)隊(duì)能夠減少制定概念和計(jì)劃階段的大量時(shí)間，將更多時(shí)間用于開(kāi)發(fā)階段，并且將重點(diǎn)放在交付更多功能和

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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