學術領域中的敏捷方法入門
在現代高等教育環境中，特別是在電腦科學與工程課程中，從傳統的瀑布式方法轉向敏捷框架已成為關鍵的學習目標。學生通常帶著對軟體開發的理論理解進入大學，卻缺乏對迭代工作流程的實際經驗。這種差距可能導致在管理複雜的畢業專題或小組作業時產生摩擦。Scrum提供了一個結構化但又具彈性的框架，能有效應對這些挑戰。
本文詳細描述了一個大學團隊成功運用Scrum原則開發行動應用程式的完整案例研究。重點不在所使用的技術堆疊，而在於促成團隊持續交付價值的流程、溝通策略與組織結構。透過檢視團隊所採取的具體步驟、遇到的障礙以及實施的解決方案，我們可以理解Scrum如何從企業環境轉化為學生主導的實踐。
專案情境
本案例研究聚焦於一群五名就讀最後一年軟體工程模組的本科生。他們的任務是設計、開發並部署一個功能完整的行動應用程式，以解決校園社群中的特定問題。專案範圍足夠廣泛，需要數月的工作，但又受到學術期限的限制。
專案目標是打造一個工具，讓學生能即時查找可用的學習空間。團隊成員具備不同層次的技能，從具備先前程式設計經驗者到完全新手皆有。這種能力組合在學術環境中相當常見，也為專案管理帶來額外的複雜性。
為了成功，團隊需要一種方法來：
- 管理相互競爭的優先事項與期限。
- 確保所有團隊成員公平貢獻。
- 隨著專案發展，適應變動的需求。
- 在考試期間維持可持續的工作節奏。
為大學團隊定義Scrum角色
第一個挑戰是分配角色。在企業環境中，角色通常高度專門化。但在學生團隊中，成員經常身兼多職。然而，為了遵循Scrum原則，團隊同意設定明確的責任分工。這種清晰性有助於避免對誰應對何事負責產生混淆。
下表說明了團隊如何將Scrum角色對應到學生的實際職責。
| Scrum角色 | 學生職責 | 關鍵關注領域 |
|---|---|---|
| 產品負責人 | 團隊負責人 | 定義功能、優先排序待辦事項清單，與指導老師協調。 |
| Scrum主持人 | 專案協調員 | 排除障礙、促進會議進行、確保流程遵循。 |
| 開發團隊 | 開發人員與設計師 | 建構應用程式、撰寫程式碼、製作UI原型、進行測試。 |
產品負責人負責專案的願景。他們蒐集潛在使用者（其他學生）的反饋，並將其轉化為期望功能的清單。Scrum主持人確保團隊有足夠的時間與空間工作，避免不必要的干擾。開發團隊具有自我組織性，代表他們自行決定如何技術性地達成產品負責人所設定的目標。
規劃階段：建立待辦事項清單
專案的基礎是產品待辦事項清單。這是一份團隊希望完成的工作項目優先排序清單。與靜態的需求文件不同，此清單是動態的，隨著團隊對問題領域的了解不斷演進。
團隊在第一週花時間建立最初的待辦事項清單。他們使用一種稱為使用者故事的技術來描述功能。使用者故事遵循一個簡單的格式：作為[使用者類型]，我希望[某個目標]，以便[某個原因]。這種格式迫使學生專注於終端使用者的價值，而非僅僅是技術規格。
初始待辦事項的範例包括：
- 作為一名學生，我希望能看到建築物的地圖，以便能輕鬆地在校園中導航。
- 作為一名學生，我希望能根據空間容量過濾房間，以便找到安靜的學習空間。
- 作為一名學生，我希望在房間變為空閒時收到通知，以便能確保有一個座位。
- 作為一名管理員，我希望能夠更新房間狀態，以確保資料保持準確。
每個項目隨後都進行了工作量估算。團隊使用故事點數而非小時數。這種方法著重於任務的相對複雜度，而非預測精確的時間框架，這在學術專案中尤其常見，因為生活事件會干擾工作進度。
執行第一個衝刺：前兩週
專案被劃分為兩週一個的週期，稱為衝刺。第一個衝刺至關重要，因為它確立了團隊的節奏。目標是產出一個可能可交付的增量，即使僅僅是應用程式的基礎版本。
衝刺規劃
衝刺以規劃會議開始。產品負責人展示了待辦事項清單中優先級最高的項目。開發團隊隨後選擇了他們認為能在兩週內完成的項目。這種承諾對確保責任制至關重要。
在這個會議期間，團隊將高階故事拆解為更小的任務。例如，地圖這個故事被拆分為：
- 整合地圖 API。
- 為房間位置建立資料庫結構。
- 設計地圖介面。
- 撰寫程式碼以取得房間資料。
這些任務根據成員的興趣與技能進行分配。Scrum 主管主持討論，以確保每位成員都理解接受標準。
每日站會
溝通透過每天固定時間舉行的會議來管理。此會議時間不超過十五分鐘。每位成員需回答三個問題：
- 我昨天做了什麼？
- 我今天要做什麼？
- 是否有任何障礙阻礙我的進度？
這種做法讓團隊保持一致。在第一個衝刺的第一週，一名開發人員報告了一個阻礙：無法存取地圖 API 文件。Scrum 主管立即介入，尋找替代資源並解決存取問題，使工作得以無延遲繼續進行。
開發過程中的障礙處理
任何專案都不可能沒有挑戰。在本個案例研究中，團隊面臨了幾項學生團隊中常見的問題。
學業衝突
在第一個衝刺進行到一半時，有兩名團隊成員安排了重要的考試。這威脅到了團隊的進度。團隊並未選擇取消衝刺或讓工作堆積，而是調整了計畫。受影響的成員在該衝刺期間減少工作量，專注於文件編寫與測試，而其他成員則承擔了開發工作。這展現了該框架的彈性。
範圍蔓延
在第一次衝刺回顧後，產品負責人收到反饋，建議增加直接預訂房間的功能。雖然這項功能很有價值，但並非當前衝刺的目標。若加入此功能，將會危及時間表。產品負責人將此請求放入待辦事項清單，以供未來考慮。這種紀律性確保了專案不會變得難以管理。
技術債
為了趕上截止日期，團隊最初選擇了一個快速但不可擴展的資料儲存解決方案。在回顧會議中，他們承認了這個決定。他們在下一個衝刺中分配了時間來重構代碼。公開承認技術債對專案的長期健康至關重要。
第二個衝刺深入探討：優化與穩定性
第二個衝刺專注於穩定性與使用者體驗。由於第一個衝刺已建立核心功能，團隊得以專注於介面優化與確保系統可靠性。
衝刺目標
第二個衝刺的主要目標是確保應用程式能處理同時使用者而不會當機。次要目標是優化視覺設計。
工作分配
本衝刺的任務更加複雜。團隊必須更緊密地協調工作。一名成員負責後端 API，另一名成員負責前端。他們頻繁會面，以確保資料格式一致。由於缺乏整合經驗，這種協調在學生專案中通常比企業環境更困難。
測試流程
團隊實施了同儕審查流程。在任何程式碼合併前，必須由另一位團隊成員進行審查。此做法能及早發現錯誤，並幫助資深成員指導資淺成員。同時也確保了程式碼庫的一致性，即使不同成員撰寫不同模組也是如此。
衝刺回顧與回顧會議
每個衝刺結束時，會舉行兩項不同的儀式：衝刺回顧與回顧會議。這兩者常被混淆，但它們的用途不同。
衝刺回顧
回顧會議是向利益相關者（指導老師與受邀學生）展示工作成果的儀式。團隊展示了可運作的應用程式。並收集了關於易用性的反饋。產品負責人根據這些反饋更新待辦事項清單。此循環確保產品始終符合使用者需求。
衝刺回顧會議
回顧會議是團隊內部的會議，目標在於改進流程，而非產品本身。團隊討論了哪些做得好、哪些出了問題，以及哪些可以改善。在第一次回顧會議中，團隊發現會議時間過長。因此，他們在下一個衝刺中實施了嚴格的計時制度。在第二次回顧會議中，他們指出透過電子郵件溝通過於緩慢，因此改為使用專用即時通訊頻道處理緊急更新。
這種持續改進的循環是Scrum的核心。它讓團隊能在累積經驗的過程中，不斷演進其工作方式。
最終成果與學術整合
學期結束時，團隊已交付了一個可運作的應用程式，並被校園內數百名學生使用。評分方式與傳統專案不同。評分不是基於單一的最終提交，而是根據團隊的流程文件、程式碼品質以及合作成效來評估。
使用Scrum提供了具體的進展證據。團隊可以向指導老師展示待辦事項清單、衝刺日誌與每日站會筆記。這種透明度讓團隊能更容易地展現其整個學期的價值，而不僅僅是在期末。
最終成績反映了團隊的努力與流程。團隊因具備適應變動的能力並維持可持續的節奏而獲得高分。指導老師指出，那些深入參與Scrum框架的學生所開發的軟體品質，高於嘗試傳統方法的學生。
未來專案的關鍵教訓
反思此案例研究，可為希望採用敏捷方法的學生與教育工作者提供多項啟發。
- 角色至關重要：即使在小型團隊中，明確界定誰負責什麼，也能避免混淆。指定的產品負責人能確保團隊打造正確的東西。
- 迭代更佳：等到最後才展示成果風險很高。每兩週展示進度，能及早修正問題。
- 溝通是關鍵：每日站會讓每個人都能及時獲知資訊，而無需召開冗長的會議。
- 流程重於工具：團隊並未依賴昂貴的軟體來管理專案。他們使用簡單且易取得的工具。重點在於互動的規則，而非技術本身。
- 接受失敗： 當事情出錯時，團隊將其視為學習的機會。回顧會議將問題轉化為可執行的改進措施。
關於敏捷學習的結論
在學術環境中使用Scrum開發應用程式的過程，突顯了迭代開發的價值。它教導學生，軟體不僅僅是程式碼，更是人與人之間的合作。該框架提供了管理複雜性的結構，同時也保留了創新所需的創造力。
對教育工作者而言，將Scrum融入課程能幫助學生為職場做好準備。對學生而言，這提供了一個實用的框架，用以管理自身的學習與專案成果。個案研究顯示，只要角色明確、儀式一致且注重價值，學生團隊就能交付專業級的成果。
此專案的成功並非來自特定技術或天才點子，而是歸功於流程的紀律。透過堅持Scrum框架，團隊保持專注，妥善管理工作負荷，並交付了符合社區需求的產品。此方法可複製應用於任何面臨類似挑戰的團體專案。
