學術界的工程專案經常反映現實世界中的軟體開發挑戰。若無結構化的做法，團隊動態可能分裂，期限可能延後，技術負債也可能累積。本指南提供全面的工程學本科學生的Scrum清單。它著重於在大學環境中實際應用敏捷原則，確保你的畢業專案順利且有效地進行。
📚 在學術界理解Scrum
Scrum不僅是一套規則；它是一種管理複雜工作的架構。對工程學生而言，它扮演著合作的支架角色。與傳統的瀑布模型（在開始時就固定需求）不同，Scrum欣賞變動。當面對不斷演變的專案需求或學期中突如其來的技術障礙時，這種適應性至關重要。
在學生團隊中應用Scrum時，目標不僅僅是交付程式碼。更重要的是學習如何迭代地交付價值。每個週期稱為Sprint，通常持續兩週。這個時間框架允許頻繁地從指導老師或潛在使用者那裡獲得反饋，同時保持前進動能。
👥 學生團隊的核心角色
明確的角色定義可避免混淆。在大學環境中，角色應輪流或根據優勢來分配。下表概述了每個角色的主要職責。
| 角色 | 主要職責 | 學生情境 |
|---|---|---|
| 產品負責人 | 定義優先順序與目標 | 代表客戶或指導老師的聲音；管理待辦事項清單。 |
| Scrum主持人 | 排除障礙 | 主持會議，確保流程遵守，並處理團隊衝突。 |
| 開發團隊 | 交付增量成果 | 負責建構、測試與文件撰寫解決方案的工程師。 |
注意：在許多學術團隊中，Scrum主持人與產品負責人角色可能由多人共用或輪流擔任，以確保每位成員都理解整個生命週期。
📋 第一階段：Sprint準備清單
在工作開始前，基礎必須穩固。此階段確保團隊對需要建構什麼以及為何要建構達成共識。
1.1 定義產品願景
- 確保所有成員都理解專案的主要目標。
- 將產品願景記錄在共用位置。
- 識別關鍵利益相關者（例如：教授、產業導師）。
1.2 建立產品待辦事項清單
- 收集所有潛在功能與需求。
- 使用以下格式將項目撰寫為使用者故事：作為一名[使用者]，我希望[功能]，以便[利益].
- 根據價值與風險來優先排序項目。高價值項目排在最前面。
- 確保每個項目都足夠明確，以便進行估算。
1.3 精煉待辦事項清單
- 定期審查頂層項目（待辦事項精煉）。
- 將大型任務拆分成較小且可管理的故事。
- 為每個項目分配粗略的估算（例如：點數或小時）。
📅 第二階段：衝刺規劃清單
規劃為接下來兩週設定節奏。這是一個團隊協作的活動，團隊決定他們能承諾交付的內容。
2.1 從待辦事項清單中選擇項目
- 審查待辦事項清單中優先級最高的項目。
- 僅選擇團隊認為能在衝刺期間完成的項目。
- 避免過度承諾；少做承諾，多做交付。
2.2 定義衝刺目標
- 為衝刺設定明確的目標（例如：「實作使用者登入系統」）。
- 確保目標與更廣泛的產品願景一致。
2.3 分解任務
- 將選定的使用者故事轉換為技術性任務。
- 根據技能與可用性，將任務分配給團隊成員。
- 為每個技術性任務估算工作量。
- 在實體或數位看板上追蹤進度。
🏃 第三階段：執行與每日站會清單
在衝刺期間，團隊專注於執行。每日站會是此階段的心跳。
3.1 每日站會
- 每天在同一時間和地點舉行會議。
- 最多保持在15分鐘內。
- 每位成員回答三個問題：
- 我昨天做了什麼？
- 我今天要做什麼？
- 有什麼障礙嗎？
3.2 管理工作流程
- 每天更新任務看板。
- 將卡片從「待辦」移動到「進行中」，再移動到「已完成」。
- 確保程式碼定期提交到程式碼庫。
- 執行自動化測試，以早期發現回歸問題。
3.3 協作
- 針對複雜邏輯使用配對編程。
- 在合併變更前進行程式碼審查。
- 在進行過程中記錄架構決策。
🔍 第四階段：Sprint 回顧檢查清單
Sprint 回顧不僅僅是示範；它是一個反饋循環。每次 Sprint 結束時都會進行。
4.1 展示增量成果
- 向利益相關者展示可運作的軟體。
- 突出顯示與原始計畫相比已完成的功能。
- 坦誠說明未完成的部分及其原因。
4.2 收集反饋
- 向利益相關者詢問關於功能性的具體意見。
- 記錄反饋，以供下一次規劃會議使用。
- 根據新的洞察更新產品待辦事項清單。
4.3 調整計畫
- 根據發行目標審查目前的進展。
- 如有必要，重新排序待辦事項清單。
- 討論產品方向可能的變更。
🔄 第五階段：Sprint 回顧檢查清單
回顧僅限團隊內部進行。這是一個安全的空間，用來討論如何改進流程。
5.1 建立場景
- 創造一個心理上安全的環境。
- 提醒團隊，目標是流程改進，而非歸責。
5.2 回顧上一個衝刺
- 什麼進行得順利？
- 什麼進行得不順利？
- 需要改進的前三項是什麼？
5.3 制定行動項目
- 識別在下一個衝刺中要嘗試的具體改變。
- 為每個行動項目分配負責人。
- 在下一次回顧會議中檢視這些項目的進展。
⚠️ 大學生常見的陷阱
即使有檢查清單，學生仍經常面臨獨特的挑戰。意識到這些常見問題，可避免專案失敗。
1. 範圍蔓延
在衝刺中間新增功能是一大風險。若出現新想法，應加入待辦事項清單，留待下一個衝刺處理。除非是關鍵阻礙，否則不要打亂當前的承諾。
2. 沉默的團隊成員
在小組專案中，有些成員可能會消失。Scrum 主管必須及早識別此情況。鼓勵成員在每日站會中參與。若某成員持續缺席，應立即處理。
3. 忽視技術債
大學專案經常為了趕期限而匆忙進行，導致程式碼混亂。每個衝刺都應分配時間進行重構與測試，不要留到最後一週才處理。
4. 忽略文件編寫
程式碼不夠。學術專案還需要報告。應將文件編寫任務納入待辦事項清單中。將文件編寫的任務與程式撰寫任務同等對待。
📊 優化管理專案產物
產物代表工作或價值。對工程學生而言，管理這些產物是組織性的關鍵。
- 產品待辦事項清單：保持此清單可見。使用共用文件或工具，維持單一真實來源。
- 衝刺待辦事項清單：追蹤每日進度。當任務完成或發現新任務時，立即更新。
- 增量：確保每個衝刺結束時都有一個可交付的產品增量。這表示程式碼能編譯、測試通過，且基本功能正常運作。
📝 評估對齊檢查清單
大學專案的評分標準通常與產業級的Scrum不完全相符。請將您的流程與學術要求保持一致。
- 檢查評分標準：確保您的Scrum活動（會議、產出物）符合課程的交付成果。
- 記錄時間： 某些課程要求記錄時間。請追蹤每位團隊成員在任務上所花費的時間。
- 期中考核： 使用Sprint回顧來模擬期中考核報告。及早獲得進度反饋。
- 最終提交： 確保最終的程式碼與報告與特定的Sprint增量相關聯。
🛠️ 溝通協議
清晰的溝通能減少摩擦。請在專案初期建立基本規則。
- 溝通管道： 明確規定在何處討論何事。為技術問題使用特定管道，其他則用於一般更新。
- 回應時間： 對訊息的預期回應時間達成共識。
- 會議頻率： 遵守時間表。如果說好早上9點，就必須準時到場。
- 衝突解決： 明確決策方式。是共識？投票？還是由產品負責人決定？
📈 追蹤進度
可視化進度有助於團隊保持動力並意識到潛在風險。
- 速度： 記錄每個Sprint完成的故事點數。利用此數據更精確地規劃未來的Sprint。
- 燃盡圖： 使用圖表顯示剩餘工作量。在Sprint期間應呈現下降趨勢。
- 錯誤追蹤： 將錯誤與功能分開記錄。不要讓關鍵錯誤阻礙Sprint目標的達成。
🎓 為未來做準備
使用此檢查清單完成專案，能為就業市場提供具體實務技能。雇主重視具備敏捷方法論經驗的人才。
- 作品集： 記錄您的Scrum流程。包括看板的截圖和回顧會議的紀錄。
- 簡歷： 列出您使用的具體工具和實務（例如：「使用Scrum框架管理五人團隊」）。
- 面試： 準備好討論您在專案期間如何處理衝突或範圍變更。
✅ 最終實施檢查清單
在開始第一個衝刺之前，請確保以下基礎項目已準備就緒。
- ☐ 團隊成員已互相介紹並分配角色。
- ☐ 已建立溝通管道。
- ☐ 已建立並分享版本控制儲存庫。
- ☐ 所有成員的開發環境均已設定完成。
- ☐ 已建立並優先排序第一個產品待辦事項清單。
- ☐ 已定義第一個衝刺目標。
- ☐ 已安排衝刺規劃會議。
- ☐ 已同意每日站會的時間段。
- ☐ 已決定回顧會議的格式。
透過遵循此結構化方法，工程系本科生可以自信地應對複雜專案。此過程具有迭代性，雖然需要紀律，但回報是獲得一個可運作的產品，以及對專業工程實務更深入的理解。
請記住，目標是持續改進。每個衝刺都提供了比上一次做得更好的機會。運用Scrum框架不僅僅是為了通過課程，更是為了為成功的工程職業生涯奠定基礎。
