在瀑布式專案中實現敏捷開發

轉自：http://www.ibm.com/developerworks/cn/websphere/techjournal/0907_hines/0907_hines.html?ca=drs-cn-0923

作者：Liz Hines, 程式主管, IBM
Scott Baldwin, ScrumMaster 和軟體工程師, IBM
Mark Giles, 開發經理, IBM
Juan Peralta, 開發專案經理, IBM

簡介

瀑布式專案方法在許多組織中都確立了十分牢固的地位，於是編寫程式碼的開發團隊通常沒有權力做出 “遷移到敏捷流程” 這一決策。在涉及到數個組織的大型專案中，情況尤是如此。

雖然已有提議讓最近的一個重點專案採用敏捷開發，但在負責專案中關鍵應用程式之一的開發團隊沒有決定更進一步、將敏捷方法應用到他們所控制的那部分專案中之前，這些提議沒能得到進展。採用敏捷開發這一決策所產生的成果證明了敏捷開發的價值和益處，更重要的專案管理團隊在整體專案環境中可理解並欣賞這種價值和益處。

本文介紹了開發團隊如何在較大型的瀑布式專案中成功地實現敏捷開發。本示例包含所執行的概念和技巧、所面臨的挑戰以及所產生的益處，可幫助您尋找到類似的有用方法，利用這種方法您可將敏捷概念和流程介紹到您的組織中。

本文假定您熟悉基本專案管理、敏捷開發概念和術語。

專案背景

作為本案例研究之物件的特定應用程式，是一款現有的由一個全球銷售團隊使用的銷售合同應用程式。此應用程式已面世數年，通常每年都發布 3 到 4 個主要或次要版本。此應用程式的客戶群很大而且多樣化，包括 3,000 名超級使用者，以及數千名臨時使用者。

這一正在進行中的專案由 CIO 辦公室管理，解決方案領導代表了客戶。專案團隊整體中的各種成員 —— 使用者、設計師、架構師、開發人員、測試人員、生產操作人員等等 —— 來自公司內的不同組織。

此瀑布式專案的整合開發流程包含以下階段：

• 制定概念前
• 制定概念
• 計劃
• 開發
• 驗證
• 首次展示

在制定概念前階段，開發團隊提供粗數量級 (ROM) 的提議釋出內容和（未確定的）目標日期。在制定概念階段，客戶為所釋出內容的候選列表排列優先順序，建立並審查業務需求和系統需求，開發團隊還提供業務需求 (BR) 和系統需求的 (SR) 的影響等級 (LOE)。在計劃階段，SR 候選列表會確定，而且開發團隊會對這些需求確立初步的規模估計。

對此專案而言，典型的計劃如下所示：

• 制定概念階段：2 個月
• 計劃階段：2 個月
• 開發階段：6 周
• 驗證階段：6 周

在這些階段（甚至是為期 6 周的開發階段）中，客戶要求 (CWN)、BR、SR 以及最後的更改請求的候選列表將持續更新並重新劃分優先順序。

就應用程式中所使用的技術而論，它構建於一個面向服務架構 (SOA) 平臺之上，利用了 IBM® WebSphere® Process Server V6.0.2.4、IBM WebSphere Portal V6.1 和 IBM DB2® 9.1.6 的高可用性功能。該應用程式利用 Web 服務以與公司內部其他應用程式相整合。此外，利用了 WebSphere Process Server 技術來管理業務規則和過程工作流。與其他內部應用程式的需求和版本釋出計劃相協調，可降低專案應用程式版本釋出的規劃和安排的複雜性。

為什麼要使瀑布式專案變得敏捷？

此應用程式每次釋出典型版本，都將大量時間（長達 7 個月的週期中的 4 個月）消耗在制定概念和計劃階段。儘管這樣，需求依然會變化。開發團隊決定尋求一種敏捷方法，因為敏捷方法可適應業務優先順序和需求的變化，並在專案進展時適應開發重構。這種方法將使開發團隊能夠減少制定概念和計劃階段的大量時間，將更多時間用於開發階段，並且將重點放在交付更多功能和更高質量上。

由於部署視窗和參與驗收測試的有效使用者是有限的，所以部署日期也受到限制，而且通常在制定概念階段早期就確定了。冗長的計劃和再計劃通常導致開發階段縮短，於是開發階段會持續混亂並必然延遲。在開發階段頻繁改變釋出優先順序並不會起到幫助作用。

開發團隊的一個主要目標是採用更好的開發流程，來控制因外部影響（後期需求、不斷變化的需求等）和自有的不良流程（不完全的開發流程、低下的程式碼質量等）而引起的混亂。採用敏捷方法可改變他們的開發文化，使其獲得流程的控制權。

除此之外，開發團隊還意識到敏捷方法的其他益處：更佳的質量、更快的實現以及更高的客戶滿意度。他們還相信，如果他們能夠推進敏捷流程，他們將有動力說服更大的專案整體改用敏捷方法。他們獲得的教訓幫助他們製作出其工具和流程的任何操作指南，並加快向敏捷流程的最終轉變。

敏捷方法真正實現的程度如何？

粗體術語是 Scrum Framework 中已定義的元素。請訪問 ScrumAlliance Web 站點了解詳情。

在專案最初開始時，開發團隊嘗試了採用一些（而不是全部）Scrum 框架 的概念，Scrum 框架是一種基於經驗流程控制理論的敏捷流程，它關注透明度、審查以及適應。該團隊實現了日常站立短會和 burndown 圖表，但選擇不採用元件來支援審查，例如 sprint 計劃、sprint 審查和回顧會議 (retrospective meeting)。

當專案進展到瀑布驗證階段 —— 在此階段中開發團隊需要處理持續的一串流程來測試缺陷 —— 團隊的 scrum 流程就結束了。當下一版本的開發階段開始時，他們必須再次啟動 scrum 流程。從根本上講，初次嘗試 Scrum 而失敗是沒有采用審查流程的結果；這一教訓在之後的 Scrum 工作中對團隊起到了幫助作用。

在更近期版本的開發階段，開發團隊決定改弦更張，引入以 Scrum 概念和特徵為基礎的完整敏捷流程。該團隊堅決進行 sprint 計劃、sprint 審查和回顧會議。更重要的是，他們致力於執行審查與自我治理。

• 角色

  為全面採用 Scrum 工作方式，團隊必須確定 scrum 團隊中的哪些成員將擔任 3 個必要角色，即產品負責人 (Product Owner)、專案經理 (ScrumMaster) 和 團隊 (Team)。最初，開發專案經理擔當主要產品負責人的身份。該團隊由現有開發團隊成員組成。被選定的 ScrumMaster 確立了週期為 3 到 4 周的 sprint 日程表， 以及不一定要與瀑布流程里程碑一致的起止日期；團隊認識到，計劃中的 sprint 會議與瀑布里程碑太近，會導致團隊重心轉移到兩個事件之一之上，而不能兼顧，那麼被忽視的事件會產生不利的結果。

• 待辦事項

  在 sprint 計劃會議上，開發團隊首先要討論的是，客戶（在制定概念和計劃階段）已針對應用程式未來版本而鑑定出的候選產品待辦事項。產品負責人挑選出這些專案的一個子集，包含考慮在 sprint 中解決的可能產品待辦事項。在 sprint 計劃會議中，開發團隊研究他們相信自己可在 sprint 中完成的產品待辦事項，從中整理出 sprint 待辦事項。這些待辦事項就是團隊要在 sprint 過程中實際處理的任務、任務評估和分配。

• 審查

  在每個 sprint 的末尾，開發團隊要舉行一個 sprint 審查會議。此會議的目的是向 stakeholders 說明 sprint 中的成果，併為涉眾提供適時的機會來評論和提問，這可能生成一份期望修改列表。這些修改和任何缺失的或錯誤的功能都新增到下一次 sprint 的產品待辦事項中。

• 回顧

  在每個 sprint 的末尾，開發團隊還要舉行一個 sprint 回顧會議，來回顧 sprint 中良好的部分和可以改進的部分。基於此反饋，他們可以適當修改流程，以及向產品待辦事項追加非功能性操作項。

• 計劃

  典型的計劃是在 sprint 結束時的同一天舉行 sprint 審查和 sprint 回顧會議，接下來的第二天就舉行下一個 sprint 的 sprint 計劃會議。這些會議在 Scrum 時間盒指導方針下進行。

• 參與者

  客戶代表 (解決方案領導者) 會參與 sprint 計劃和 sprint 審查會議。最初，客戶的利益由開發專案經理代表，但在之後的 sprint 中，開發團隊能夠使解決方案領導者介入，通過這些關鍵參與者獲取直接的客戶輸入和反饋。這種方法目的很明顯；團隊希望良好地理解流程與方法，然後再擴大參與者圈子，讓解決方案領導者加入。

• 使用者案例

  開發團隊還在計劃中採用了使用者。雖然客戶代表（解決方案領導者）應當負責建立使用者案例，但開發團隊根據現有需求為之代勞了，因為更大的專案尚未使用敏捷流程。然後該團隊讓解決方案領導者參與驗證使用者案例，合作改進案例並更好地理解需求。這一實踐極大程度地改善了對需求的理解和需求的準確度，並且顯著減少了實行之後的返工。

• 質量保證

  開發團隊曾長期使用連續累計，但他們最近將自動測試引入到了開發流程中。直到自動測試可用並且融合到測試工具中，才能認為工作項是完整的。每日構建和自動測試可確保在程式碼簽入時不破壞編碼基數。這會生成高質量程式碼，並減少驗證階段中將發現的缺陷。直到功能可以在活動伺服器上驗證，才能認為編碼項是完整的。例如新流程或文件等非編碼項，發表在開發團隊的內部 wiki 上，並分發給團隊，以便在完整呈現於 sprint 審查會議上之前先進行審查。

  其他敏捷元素

  因為開發團隊依照嚴格瀑布式流程而運作，所以他們不能全方面採用敏捷開發。團隊仍然履行一個需求週期，以將 CWN 細化為 BR 和 SR、劃分優先順序、ROM、LOE 和初步規模估計、新增新需求，以及重複地迴圈。

  開發團隊能夠在需求週期中促成一些改進；例如，他們能夠處理由客戶代表核對過的優先列表，能夠在需求週期中根據不同要點篩分使用者案例，從而構建候選作用域列表以供客戶審查。團隊利用了 Scrum 流程來處理這種活動，針對需求週期生成了必要的工作產品，最終減少了開發階段可怕的需求混雜。

  如果專案完全改用敏捷流程，使用者案例有希望在週期之初就確立，優先順序的劃分有希望限於 1 或 2 個週期中完成，而且更多時間有希望用在開發階段。敏捷採用的這種狀態可支援與客戶一起審查已實現的特性，並且根據客戶反饋來更新功能，而不是在檔案上多次重新修改不同等級的需求。

  開發團隊沒有完全依靠 sprint 待辦事項和 burndown 圖表工具來分配和跟蹤工作，而是使用了一個傳統的 Microsoft® Project 計劃來在開發階段安排任務。這種做的理由有很多。首先，這向客戶證明了分配給此專案的資源已完全利用，交付了儘可能多的內容。其次，Microsoft Project 是瀑布式專案中備受期待而且更受認可的狀態交流方式。然而，在更新狀態時除了專案計劃外還參考 burndown，開發團隊就採取了措施，使其他團隊接觸並過渡到敏捷跟蹤方法。

  應對挑戰

  當然，以兩種內在特性不同的專案管理風格（和文化）來進行工作，會給開發團隊帶來諸多挑戰：

  • 語言

    從瀑布流程過渡到敏捷流程時，一個重要挑戰就是要銜接術語。在本專案中，開發專案經理非常出色地進行了術語轉換，既同客戶以瀑布形式交流，又彌合了敏捷環境和瀑布環境中相對應的工具和狀態之間的差異。藉助這種適當的 “銜接”，開發團隊更加自由地採用自己的流程，並且採取了本文所述的循序漸進的步驟。

  • 計劃

    開發團隊的標準運作模式是持續執行 sprint 週期 —— 不管他們是否正特別處理一個候選釋出版本。所以，sprint 包含了規模估計工作、生產支援活動以及驗證工作。因此，該團隊嘗試不使 sprint 在開發轉換里程碑 (DCUT) 之日啟動和中止。同樣，使 sprint 不在 DCUT 之日結束也很有用；在那個重要時期抽出兩天進行必要的會議，這不利於目標版本進入驗證階段。sprint 通常在 DCUT 之後的一週結束。

  • 支援

    最初，開發團隊努力在 sprint 中處理必然的產品支援。一些開發人員專門處理 3 級支援，但是出現的產品缺陷中多數需要整個開發團隊的成員來解決。儘管不能全面計劃所有這些工作，但是可預計一些與支援相關的常規工作。這種工作分兩部分執行：分析和解決。有助於團隊將產品支援整合到 Scrum 模型之中的基本原則是，將任意產品缺陷的優先順序設為最高的可能值，於是初始分析會優先於開發人員手頭或者任務列表中的任意其他工作。

    在分析方面，當產品缺陷生成時，通知單會新增到當前 sprint，並根據嚴重性而分配。執行根源分析，可確定提供解決方案要涉及的工作，而且此分析將找出問題的原因（或者，如果原因不明顯，則找出識別原因所必要的內容），預估實現修復和建立單元測試的規模以及實現修復的困難度。一旦上述工作完成，通知單會從當前 sprint 中移除，產品負責人會確定與產品待辦事項中其他專案相比的優先順序。根源分析預定要在現有服務水平協議 (Service Level Agreement) 需求的範圍內執行。

    然後產品負責人將問題分配到 sprint 待辦事項（可能是當前 sprint 或者將來 sprint 的產品代辦事項），那麼之後會通過一個釋出版本、一個修復程式包或小修補程式而實現修復。

    開發團隊估計在部署新版本之後的兩週內，每週會出現 10 個缺陷，如果進行過 4 小時的分析，則每週出現 3 個缺陷。

  • 更改

    產品問題會週期性地引發更改請求。開發團隊的指導方針指出，這些請求必須由產品負責人為之在 sprint 中劃分優先順序。如果產品負責人相信更改請求是開發團隊的最優先事項，那麼 ScrumMaster 和產品負責人要確定當前 sprint 是否應當調整或（在罕見情況下）暫停，以適應這些請求。

  • 轉換

    基礎架構團隊是開發團隊的一個子集，他們負責編譯工具、（測試和生產）伺服器管理、資料庫管理等。此團隊分配在 sprint 之中，但他們也定期接收到來自專案中其他團隊的工作請求。這違背了 Scrum 的原則，該原則宣告團隊要單獨執行其 sprint 工作。

    為緩解此問題，開發團隊利用了 3 個戰略：

    • 團隊識別出應當在每個 sprint 中都包含的基礎架構任務，並將這些任務加入 sprint 待辦事項（例如，alpha 部署、beta 部署支援、產品線上備份等）。
    • 識別與產品待辦事項相關的任意基礎架構任務，並將之加入 sprint 待辦事項。
    • 基礎架構團隊領導被指定為外部技術架構技能請求的焦點，與產品負責人合作確定這些工作項的優先順序，並根據需要將工作項加入 sprint 待辦事項。

    基礎架構團隊成員瞭解到要拒絕這種干擾，於是遵從上述流程來處理這類請求。這使他們能全身心地繼續從事於 Scrum 流程。

  • 規模

    由於其規模，開發團隊最終會轉移為 Scrum 團隊的一個層次，劃分為 4 個團隊：

    • 業務流程/後端服務
    • 使用者介面
    • 生命週期管理
    • 基礎架構

    這些團隊在內部執行每日 scrum。每兩週舉行一次 scrum 的 scrum，每個 Scrum 團隊有一名代表參加並總結最近一次會議以來他們團隊的狀態、下一次會議之前該團隊的計劃、任意現存障礙，以及他們會對其他 Scrum 團隊造成何種干擾。

    使用的工具

    開發團隊利用一個 bug/問題跟蹤系統，該系統提供一個具有便利的報表程式的整合 Wiki。IBM Rational Team Concert™ 提供這種功能。團隊針對所有開發工作項建立跟蹤單，併為 sprint 生成（在其他報表之中的） burndown 圖表。團隊還能擴充套件工具和 Wiki 來適應自身需求。例如，團隊可建立整合到 Wikipedia 之中的使用者案例工具。

    開發團隊大量利用開發 Wiki 來記錄流程，提供對進度報表的訪問，以及接入其跟蹤系統。因為接入跟蹤系統，Wiki 是一種特別好的、用於文件編制和協作的機制。

    開發團隊在 Microsoft Project 中構建專案計劃。專案計劃引用了計劃所包含的每個低階計劃的跟蹤單；這是在遷移到敏捷流程之前開始的演化。不是在相關時間內引用一個 CWN，而是為在一個版本中交付 CWN 所涉及的每個任務建立跟蹤單。在可能的情況下，會細分任務，並將時間分配給兩個或更多開發人員，從而提高工作效率並減少整體編碼時間。細分出的每個任務都獲得自己的跟蹤單，並在專案計劃中單獨引用（目的是使每個任務單/任務最多隻有一名所有者）。專案計劃也會為個體開發人員確定任務優先順序，還確定候選版本的整體優先順序。在跟蹤單上會建立一個自定義優先順序欄位，此欄位根據專案計劃而更新，並且按照開發人員執行任務的正當順序傳達給他們。

    實現的獲益

    正如預期和宣傳的那樣，採用敏捷流程的結果就是提高了程式碼質量、加快了實現、提升了客戶滿意度，而且優化了開發流程。開發團隊還獲得了其他益處，包括一些通常被認為和敏捷無關的益處：

    • 處理大型任務

      採用 Scrum 的重要益處之一就是，Srucm 使開發團隊能夠將高價值專案加入版本中。這可能違反直覺；畢竟依照一些說法，限制在 2 周到 4 周之內的 sprint 不能處理大型功能。在本專案中，大型特性很難填入到一個版本的優先表中；比起一個大專案，客戶通常更願意選擇 10 個較小的專案，即使那個大專案很重要。Scrum 強制開發團隊逐步重視這些大型特性，分解大型特性以進行分析或研究，然後增量式地實現。團隊能夠在與開發階段無關的 sprint 中良好地分析或研究，根據要求完成前置任務，然後更易於將增量實現加入到版本優先事項中。

      這種方法也適用於非功能性專案，例如程式碼重構和自動化整合測試。很難讓客戶相信這種工作很重要，但是開發團隊能夠將重構工作打散成小塊，構建一個漸進的變更計劃，然後在 sprint 和版本中實現增量式變更。

    • 靈活性

      與此相關的益處是，可獲得解構大型任務的能力和規程；sprints 強制開發團隊以對待較小規模任務的方式思考。對於較小的任務，團隊能更好地計劃版本內容，還能在任務發生意外的情況下重新分配資源。大型任務往往需要更廣泛的技能和專業知識，但是分解成小任務之後，很多都能分配給技能範圍較窄的開發人員，這就提高了資源分配的靈活性。在數個版本和多個 sprint 計劃會議之後，這種 “小任務” 理念就能在整個團隊的頭腦中生根了。

    • 流程改進

      Scrum 流程還提供了一個框架，以實現開發團隊之前所缺乏的增量流程改進。Sprint 回顧會議提供了有用的反饋，而且流程更改新增給下一個 sprint。在一些情況下，例如在生產支援和基礎架構團隊的任務中，需要數個 sprint 來細化流程從而鑄造成功。團隊忠實於流程，解決了問題，並構建了很好地為團隊工作的流程。

    • 處理更改

      開發團隊能更好地處理變更，即使是在 sprint 中期。在一個版本釋出過程中，他們攜著對優先事項的清晰理解，開始了開發階段；然後在一個 sprint 的中期，客戶帶來了全新的最優先事項。通常這種混雜會挫傷團隊士氣，但他們利用了 Scrum 原則來討論可選項（中斷 sprint 並重新開始，或者繼續遵從不正確的優先順序列表）。因為開發團隊被授權制定決策，所以他們能夠改變方式，接受全新的優先順序，以獲得成功。

    • 工作環境

      Scrum 流程的採用對團隊士氣、團隊紀律以及團隊互動具有重大的影響。因為開發團隊被授權改進自己的流程，所以他們徹底忠實於流程，充滿活力與激情地面對一切。創造力被應用到流程改進中，這種創造力更擴充套件到團隊的開發工作中。此外，更新的流程會極大地改善開發週期，減少 DCUT 里程碑期間的恐慌，還減少在驗證階段及生產階段中所發現缺陷的數量和嚴重性。版本釋出流程將更加穩定、工作計劃更周密，而該團隊體驗到的混亂時間更少。工作時間的預測性更強，即使團隊到達了關鍵日期，這提高了士氣並減少了開發人員與處理該專案的其他團隊之間的壓力。

      結束語

      敏捷開發的價值和益處逐漸變得明晰，而且獲得了令人印象深刻的成果。在應用程式下一個釋出版中使用 Scrum 將整個專案遷移到敏捷流程；針對該版本的敏捷研討會剛剛舉行。開發團隊將能輕鬆保留開發流程，通過調整區域性方法來適應更大型的敏捷流程。

      作為開發計劃和跟蹤的一部分，開發團隊擁有一個不合格的冗長候選待辦事項（CWN 和缺陷）。它們將儲存在團隊的問題跟蹤工具中，並引入到全新敏捷流程中，以備在將來版本中得到考慮。

      開發團隊中的巨大變化就是，使用者案例由專案負責人開發。這一工作以開始敏捷研討會為起始，使用 Rational Team Concert 作為首選工具。因為使用者案例流程提出了更高的質量要求，所以專案負責人致力於此，推動使用者案例將極大地改進流程。

      另一個重要改變就是，將 Scrum 團隊從當前孤立的結構（基於開發中的功能域）轉換為一個包含了專案代表的結構。以前，由於 Scrum 僅限於開發團隊，所以職能的劃分是必然的。在開始研討會上，針對下一個版本討論並制定了團隊結構。開發團隊已採取措施，針對當前版本而遷移到混合團隊結構，他們將在流程中進行審查和修訂，並將積累的經驗教訓應用到下一個版本。

      開發團隊逐漸轉向測試驅動方法，並已採取措施與測試團隊接觸（測試團隊在獨立的組織中）。開發團隊將與測試團隊合作，讓後者加入 sprint，向他們傳授 Scrum 概念，並且共同在整個專案中採用敏捷開發。

      最後，未來計劃包括，向專案整體中的合作伙伴團隊宣傳 Scrum 和敏捷原則。開發團隊的經驗使他們處於培訓角色的地位，這不僅是因為他們擁有敏捷知識並吸取了教訓，還因為他們最瞭解應用程式的工作方式，而且體驗過在組織中使用敏捷開發。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-615446/，如需轉載，請註明出處，否則將追究法律責任。