敏捷開發框架下的軟體工程 / 第一次迭代 / 規劃遊戲
| 規劃遊戲 |
|
 |
軟體工程的目標是按時、在預算範圍內交付滿足需求的軟體。正如我們所學，傳統的計劃驅動方法始終未能實現這一目標。其中一個關鍵因素是需求收集策略。計劃驅動的瀑布模型方法在早期階段徹底確定需求，然後使用這些需求來指導後續流程。問題是：當需求發生變化時會發生什麼？這可能發生在業務本身發生變化時，或者不同的使用者考慮軟體並提出替代應用，或者客戶對軟體的可能性有了更深入的瞭解。
• 需求是指一個陳述，它識別出定義產品或流程需求的功能、物理特性或質量因素，這些需求將尋求解決方案。
功能需求描述系統做什麼（功能）。
例如，“系統應為學生註冊課程”
非功能需求描述系統具有什麼（物理特性）。包括可靠性、質量、安全性和可維護性。
客戶和開發人員之間的討論中，一個挑戰是使用的語言。客戶是其業務領域的專家，並將使用適合該領域的語言。例如，會計師將使用“投資回報率”（ROI）或“淨現值”（NPV）等術語。在教育領域，“學習路徑”（POS）或“全日制等值學生”（EFTS）等短語是熟悉詞彙的一部分。與此同時，開發人員熟悉技術術語，很容易用這種行話讓客戶感到困惑。
敏捷方法使用一種需求確定方法，可以描述為“及時”需求分析。與客戶和/或使用者舉行會議，在此期間，根據對問題的當前理解，對需求可能是什麼做出最佳猜測。使用的語言必須讓客戶和開發人員都能理解，因為該過程是持續對話的開始，這種對話將在整個開發過程中持續進行。
肯特·貝克在他的《極限程式設計》（2005 年）中描述了一個正式的需求收集過程，稱為“規劃遊戲”。這是定義的極限程式設計實踐之一。請記住，極限程式設計中的關鍵價值觀是
溝通 簡潔 反饋 勇氣 尊重
規劃遊戲透過鼓勵整個開發團隊（包括客戶）儘早進行有效的討論來應用這些價值觀。使用者故事被記錄在索引卡上，並顯示給整個團隊進行討論。然後，它們被用於規劃開發，包括髮布和時間估計。團隊成員對卡片進行優先順序排序，討論約束並描述故事完成的測試。邁克·科恩 (2004) 將使用者故事應用於敏捷開發，發展了貝克的思想。
“使用者故事描述了對系統或軟體的使用者或購買者有價值的功能。”（第 4 頁，科恩，2004 年）
該故事描述了使用者在一次會話中將要執行的操作，例如，“學生將訪問專案檔案”，“學生小組將同時訪問專案檔案”。
使用者故事包含三個部分
1. 故事本身
2. 評論，可能澄清故事的細節，或提出待討論的觀點
3. 用於指示故事完成的測試
傑弗里斯 (2001) 將撰寫使用者故事的過程描述為“卡片、對話和確認”。卡片用於捕獲初始需求，然後在團隊中進行討論，然後實施和測試。這強調了故事作為溝通工具的作用，在開發過程中使用。它們不用於記錄流程，也不是合同義務。傳統的需求文件同時兼具這兩者。
使用這種方法允許團隊在整個專案持續時間內分散決策。可以儘早做出宏觀決策，這允許進行初始規劃。根據需要，可以稍後新增詳細資訊。早期的、大型的故事被稱為“史詩”。
一個故事有多大？
理想情況下，它描述了一個需要 1/2 到 10 天編碼的任務，假設開發團隊經驗豐富。學習估計故事的大小對於開發人員來說是一項重要的技能。規劃每個迭代中將包含哪些故事取決於良好的時間估計。
為什麼要使用故事卡？
它們強調口頭交流而不是書面交流
它們易於所有團隊成員理解
它們有助於有效規劃
它們支援迭代開發
它們鼓勵推遲細節（科恩，2004 年）
一個好的故事是：• 獨立的 • 可協商的 • 對使用者或客戶有價值的 • 可估算的 • 小的 • 可測試的
（韋克，2003 年 a）
 案例研究 Shac09 |
|
小組：軟體工程 2007
透過思考各種系統隱喻，班級能夠編寫大量關於參與隱喻中的人物的故事（例如司法系統 - “律師申請重審”）。這些故事很容易轉換為真實系統 - 一個支援可持續房屋建築競賽的資訊系統。然後，這些使用者故事透過計劃遊戲進行分類和排序。
|
