敏捷實施：學術畢業專案的逐步指南

學術畢業專案代表學生教育歷程的總結。它需要規劃、執行並交付一個重要的成果。傳統上，這些專案採用線性、瀑布式的做法。然而，現代課程越來越傾向於使用敏捷方法。這種轉變使學生能夠適應不斷變化的需求，並逐步交付價值。

本指南概述了如何將敏捷原則應用於學術畢業專案。內容涵蓋準備、執行與審查。重點在於流程與合作，而非特定的軟體工具。學生與教育工作者可利用此架構有效管理複雜任務。

為什麼敏捷方法適合學生專案 💡

畢業專案通常持續數個月。在此期間，需求可能變動。教師的反饋可能改變專案範圍。敏捷方法比僵化的計畫更能適應這些變動。

• 適應力： 隨著你對問題了解得越多，就能調整計畫。
• 頻繁反饋： 與指導老師定期溝通，可避免重大偏差。
• 風險降低： 以小規模逐步建構，可降低最終完全失敗的機率。
• 團隊合作： 每日溝通可確保所有人目標一致。

實施此方法並不代表放棄文件記錄或結構。這意味著將工作組織成可管理的週期。每個週期，通常稱為一次衝刺（sprint），都會產生具體的成果。

第一階段：準備與規劃 📋

在撰寫程式碼或進行實驗之前，團隊必須建立基礎。此階段為整個專案生命週期奠定基礎。

1. 定義專案願景

每個敏捷專案都從明確的目的開始。撰寫一段陳述，描述所要解決的核心問題。此願景如同指南針。當團隊面臨困難決策時，應回顧此陳述。

• 主要目標為何？
• 最終使用者是誰？
• 存在哪些限制條件（時間、預算、技術）？

2. 建立初始待辦事項清單

待辦事項清單是一份按優先順序排列的專案完成所需所有任務的清單。在學術環境中，這包括研究、開發、測試與文件編撰。

• 使用者故事： 從使用者的角度來描述任務。範例：「作為一名學生，我需要提交作業，以便教授能夠評分。」
• 估算： 為每一項任務分配相對的工作量點數。可使用簡單的等級（低、中、高）或數值。
• 優先順序： 根據重要性與依賴關係對項目進行排序。

3. 建立角色與職責

即使在一個小型學生團隊中，明確的角色也有助於維持秩序。將產業中的角色調整以適應學術環境。

• 產品負責人： 通常是由學生或小組負責人與教授溝通。他們確保專案符合評分標準。
• 開發團隊： 負責執行工作的成員。他們自行組織以完成任務。
• Scrum 主管： 一名促進者，負責排除障礙。此角色可輪流擔任，以確保所有成員都理解流程。

第二階段：Sprint 循環 ⏳

Sprint 是短暫且固定長度的工作期間。在學期情境中，一個 Sprint 可能持續一到兩週。每個 Sprint 結束時，會對已完成的工作進行檢視。

1. Sprint 規劃

在每個週期開始時，團隊會從待辦事項清單中選擇項目。目標是承諾完成一個實際可行的工作量。

• 檢視待辦事項清單： 檢視優先級最高的項目。
• 容量規劃： 考慮考試時間表和其他課程作業。不要過度承諾。
• 定義 Sprint 目標： 到結束時，將達成哪個具體的里程碑？

2. 執行與每日站會

在 Sprint 期間，工作開始進行。為保持進度，應舉行簡短的每日會議。每次會議不應超過 15 分鐘。

三個關鍵問題：

• 我昨天完成了什麼？
• 我今天將做什麼？
• 是否有任何阻礙影響進展？

如果存在阻礙，團隊必須立即處理。這可能意味著向同儕尋求協助，或聯繫指導老師。

3. 進行中工作數量限制

同時開始太多任務會導致切換情境。應專注於完成一個項目後再開始另一個。這個概念稱為進行中工作（WIP）數量限制，能提升品質與速度。

• 單一任務專注： 避免在複雜的程式設計或寫作任務上同時處理多項工作。
• 品質檢核： 在進入下一個項目前，確保工作符合標準。

第三階段：審查與回顧 🔄

每輪衝刺結束時，會舉行兩場特定會議。第一場審查工作成果，第二場審查流程。

1. 迴圈審查

這場會議向利益相關者展示已完成的工作。在學術環境中，這可能是指導教授或一組同儕評審委員。

• 展示：展示實際的產品、原型或報告內容。
• 討論：說明哪些做法有效，哪些沒有。
• 更新待辦事項清單：根據反饋，新增任務或修改現有任務。

2. 迴圈回顧

這場會議是團隊內部進行的，專注於改善團隊合作的方式。

• 哪些方面做得好？找出可重複的成功經驗。
• 哪些方面出了問題？找出需要解決的摩擦點。
• 行動項目：制定具體步驟以改善下一個衝刺。

範例行動項目：「將會議安排在週一至週三，以避免周五疲勞。」

第四階段：管理範圍與時間 ⏰

學術截止日期是固定的。與商業專案不同，你無法無限期延後交付日期。管理範圍至關重要。

1. 處理範圍蔓延

當新增功能卻未調整時程時，就會發生範圍蔓延。在畢業專題中，這通常發生在學生研究過程中發現有趣構想時。

• 記錄構想：另設一份「可有可無」清單。
• 權衡取捨：若新增功能，則移除較低優先級的功能以維持時程。
• 指導教授同意：在對核心範圍進行重大變更前，請先諮詢指導教授。

2. 時間區塊化

為特定任務分配固定時間。如果任務在時間盒內未完成，則暫停或移至待辦事項清單。

• 防止完美主義： 強制團隊交付可用版本，而非完美版本。
• 聚焦努力： 鼓勵首先尋找最簡單的解決方案。

常見挑戰與解決方案 🛠️

轉向此方法論會帶來特定挑戰。下表概述了常見問題與實用解決方案。

挑戰	影響	解決方案
工作負荷不均	部分成員的工作量多於其他成員	使用可見的任務看板來追蹤貢獻。輪換角色以平衡努力。
溝通缺口	成員錯過更新或會議	設定標準的溝通管道。立即發送會議摘要。
技術債務	快速修復會導致未來問題	安排特定迭代專門用於重構與文件編寫。
衝突的優先事項	團隊成員有不同目標	在規劃期間對齊「迭代目標」。重新審視專案願景。
學術衝突	考試或其他課程會中斷進度	根據學術日曆規劃迭代。在考試週調整容量。

敏捷環境中的文件編寫 📝

一個常見的誤解是敏捷代表不需要文件。在學術專案中，文件編寫通常是評分要求。敏捷文件編寫著重於價值與必要性。

• 即時： 在需要進行下一步時再撰寫文件，而非事先撰寫。
• 使用者手冊： 關注如何使用最終產品。
• 技術規格： 記錄影響未來工作的架構決策。
• 會議記錄： 保留回顧與規劃期間所做決策的紀錄。

使用中央儲存庫來存放所有文件。確保所有文字與程式碼檔案都使用版本控制。這可確保變更歷史得以保存，以供評估。

團隊動態與衝突解決 👥

在團隊中工作具有挑戰性。學術壓力會增加壓力。健康的團隊動態對成功至關重要。

1. 心理安全感

團隊成員必須感到安全，才能承認錯誤。如果成員隱藏錯誤或延遲，整個專案都會受損。

• 鼓勵公開討論錯誤。
• 專注於問題，而非個人。
• 將失敗視為學習的機會。

2. 衝突解決

意見分歧會發生。應使用結構化方法及早處理。

• 數據驅動決策： 使用專案數據來解決技術爭議。
• 調解： 如果團隊無法達成共識，請教授或中立的同儕進行調解。
• 共識： 目標是達成共識，但不要讓一個人的意見主導整個團隊。

與評分標準對齊 📊

學術專案會被評分。敏捷流程必須與專案評估方式一致。

1. 映射交付成果

開始前先檢視評分標準。找出哪些標準對應到敏捷產物。

• 流程： 文件化的回顧與會議記錄顯示流程的遵守情況。
• 產品： 可運作的原型或最終報告顯示產品品質。
• 個人： 透過任務完成記錄追蹤個人貢獻。

2. 證據收集

保留每個迭代的證據。這在最後的答辯或展示時會有幫助。

• 不斷演進的產品截圖。
• 團隊會議紀錄。
• 版本控制歷史。

最終交付與展示 🎤

專案以最終展示告終。這正是所有迭代工作的總結。

1. 最終演示

展示全部功能。強調產品如何隨時間演變。解釋過程中所做的決策。

• 敘事：敘述從最初構想到最終產品的整個歷程。
• 挑戰：誠實談論克服的障礙。
• 未來工作： 建議若時間更充裕可增加的內容。

2. 專案結束後的反思

在獲得最終成績後，團隊應反思整個學期的過程。他們會做哪些不同的事？

• 迭代的長度是否合適？
• 團隊溝通是否有效？
• 該方法論對最終成果的品質有何影響？

這種反思有助於提升未來專案的表現。它鞏固了過程中所獲得的技能。

結論 🏁

將敏捷方法應用於學術畢業專案，提供了一種結構化的方式來管理複雜性。它強調適應性、合作與持續改進。透過將工作分解為較小的週期，團隊能保持動能並回應反饋。

此過程需要紀律。學生必須承諾定期會議與誠實報告。然而，其帶來的好處遠超過付出的努力。在專案管理、溝通與迭代開發中所學到的技能，能幫助學生為職場環境做好準備。

從小處著手。專注於核心目標。經常迭代。這種方法能確保學術旅程的成功完成。