敏捷專案管理如何應對常態維運與需求變化

🔖標籤 #專案管理 #agile #會客室

[!AI] 本文摘要
如何將敏捷專案管理應用於實際工作，特別是面對常態維運等小工作（如來電協查、小BUG修改）的情況下，如何納入敏捷流程，以達到持續交付可運作且改進過的軟體增量。

在當今快速變化的商業環境中，客戶的需求和期望不斷演變，這使得專案管理面臨著前所未有的挑戰。當客戶提出問題時，這不僅是對我們服務的考驗，也是改進和創新的機會。本文將針對客戶的問題進行深入分析，探討如何有效地將常態維運工作納入敏捷專案管理中，並提供具體的解決方案。

1.有關常態維運(ex, 來電協查、小BUG修改)，這些很小但有可能會佔據時間，是否能納入敏捷，若可以的話，它的產出會是什麼呢？

本題與題3一起回答

常態維運等小工作（例：來電協查、小BUG修改）雖然工作量不大，但也可能佔據相當時間。根據 Cynefin 框架(圖：Cynefin Framework―決策者的工具)，常態維運這類小工作屬於「明顯」（或稱為「簡單」）的領域。在這個象限中，工作內容通常是已知的、可以透過既定的程序或最佳做法來處理的。

若納入敏捷方法做專案管理，可以將這類工作當作待辦事項（Backlog Item）納入Sprint中，其產出就是「可運作且改進過的軟體」，包含錯誤修正、服務改善或技術債務的降低。如果這些項目達成了預先訂定的「完成定義（Definition of Done）」，那即使變更較小，也算是一個有價值的Sprint增量。

在面對常態維運等小工作與當前專案Sprint無關的情況下，產品經理可以採取一些策略來管理團隊的人力資源。首先，進行人力盤點是必要的(表格Man-Days)，這樣可以了解每位成員在接下來的Sprint中能投入多少時間，考慮到假期、會議等因素後，能夠更準確地評估可用的人天(Man-Days)，掌握更正確Sprint 生產速度。

根據這些數據計算出Scrum團隊的總人天，這有助於確定團隊的實際工作能力，並為後續的任務分配提供依據。然後，在Sprint規劃會議中，產品經理可以根據業務需求和技術債務的緊急程度，對待辦事項進行優先級排序，確保最重要的工作能夠優先處理。

在任務分配上，團隊可以根據成員的專長和可用時間進行合理分配(在我以前的團隊是認領任務制，這與目前所在單位有所不同)，這樣每個成員都能在其能力範圍內發揮作用，避免因人力不足而影響專案進度。

在Sprint執行過程中，若出現突發狀況或新的優先事項，團隊應隨時調整任務的優先級和分配，以應對變化，實務的作法是開需求梳理會議來因應這類情況。

題3的回答

敏捷方法強調每個Sprint都應交付「潛在可投入（potentially shippable）的增量」，也就是說程式部分必須達到預先約定的「完成定義（Definition of Done）」下圖(Definition of Done（DoD）一完成的定義)。這通常包含了功能測試通過、整合完畢以及符合品質標準。至於題的問題中，Sprint之產出是否一定需要上版至正式資料環境（OL）則取決於團隊對「完成」的定義。

通常期望的狀況是：只要程式能執行且符合品質要求(QA/QC)，就能算作完成。若上版流程是另一項工作（例如發行流程），那就需要在DoD定義中明確劃分(圖：Definition of Done（DoD）一完成的定義)。但整體而言，Sprint的成果應具備立即交付或在短期內可交付的條件。是否一定需要上版至正式資料環境（OL）則取決於團隊對「完成」的定義。我過往的經驗，通常團隊期望的狀況是：只要程式能執行且符合品質要求，就能算作完成。若上版流程是另一項工作（例如發行流程），那就需要在定義中明確劃分。

2.大部份子系統為1 人系統(PO 、開發為同一人時)，可以實施敏捷嗎?若可以，要如何安排呢?

當 PO 與 Scrum Master 角色合併時，可能會因產品交付的壓力而忽視敏捷實踐。圖為我在分享敏捷專案管理知識課程中有關(圖：團隊角色合一的可能性)的內容。當出現人員的角色重疊的情況，將使得在自我約束和專注於真正具體且有價值的工作上變得更加困難。因此，應該明確劃分角色，讓 PO 專注於產品規劃(如何避免出現人員的角色重複，取決管理者的決心，非在敏捷中可以獲得解決)，而 Scrum Master 則專注於團隊的敏捷轉型。%% %%

假若工作安排上不可避免在此角色重疊之下非要實施敏捷，則可以依照以下建議進行：

• 規劃固定短期迭代（Sprint），先行訂定好優先順序與明確目標。
• 利用看板或任務列表管理待辦事項，同時保持自我回顧與檢討。
• 確保每個 Sprint 結束時能產出達到「可交付」的軟體增量。

3.Sprint 之產出，程式的部份是否要可執行，須上版至OL 才能算完成嗎?

請見題1後半段的回答

4.在執行Sprint 期間，若有重要且有時限之項目須處理，以致影響到原工項進行時，我們可以做什麼調整呢?

Spint 有個活動(圖)，叫做需求梳理會議。這個會議主要目的是讓團隊和產品負責人定期檢視並更新產品待辦事項列表，以確保需求能夠及時反映市場變化、客戶反饋、新想法或技術挑戰。

產品負責人要定期梳理產品待辦事項列表(圖：Product Backlog由產品負責人掌控)，不斷地更新，以反應客戶需求的的變化、新想法或見解、競爭而導致的變化、出現的技術障礙等(圖：湧現式的需求)。當影響到原工作進行時，一種作法是在規劃會議前將欲保留適當人力(題1有帶到)，以面對這種風險。

5.若某些工項有相依性及循序性，因工時的關系須分在不同 Sprint 完成，那前1 個Sprint 之產出(無法獨立執行)是否能視為完成?

有些任務之間有依賴或必須按順序完成，可能需要跨好幾個 Sprint 才能完全做完。如果第一個 Sprint 的成果必須依靠接下來的 Sprint 才能發揮作用，那我們在拆解任務時就需要做調整，讓每個 Sprint 都能產出一個獨立有用的結果。當然，因為時間或人力有限，有時這種情況難以避免，所以就得讓團隊和所有相關人員一起達成共識，並在回顧會上討論如何改善任務拆分(個人認為回顧會議是整個Scrum流程中最重要的會議，因為它提供團隊一個反思與改進的機會)，才能更好地符合敏捷「完成定義」的要求。

故事的優先級反映出工作的相對重要性，通常會從四個面向進行評估(圖：價值驅動一用戶故事優先級)，其中相依性是一個重要的考量。

如果一個故事與其他故事之間有很強的依賴關係（上圖中相關性作為重要參考依據），通常會將它們安排在同一個 Sprint 或相鄰的 Sprint 中。透過故事地圖，可以清楚呈現專案整體樣貌，幫助團隊掌握各個故事之間的關聯和優先順序。這樣一來，根據這些面向排序後，團隊能夠聚焦於那些對實現最小可行產品（MVP）最為核心的功能，並進一步合理安排上線計劃。此外，故事地圖方法有助於識別潛在風險和依賴關係，從而在開發過程中提前進行協調和調整，提升整體專案的成功率和產品質量。

總結

1. 常態維運等工作雖規模小，但由於可預測且程序清晰，屬於 Cynefin 框架中「明顯」領域，可將其作為待辦事項納入 Sprint，交付包含錯誤修正、服務改善及技術債務降低的成果。針對與專案無關的小工作，則需進行人力盤點，合理分配團隊資源，並在 Sprint 規劃時依據優先順序處理。

2. 碰到團隊中人力一人身兼 PO 與開發（甚至 Scrum Master）時，容易因產品交付壓力而忽視敏捷實踐。文章建議若可能，應將角色分離，讓 PO 專注於產品規劃，而 Scrum Master 則帶領團隊實踐敏捷轉型；若必須合併，則可透過固定短迭代、看板管理及穩定產出達到可交付軟體增量的方法來彌補不足。

3. 關於 Sprint 產出是否需上版至正式資料環境，則視團隊對“完成定義（Definition of Done）”的規範而定。只要程式能執行並符合質量要求，即可算作完成；若上版流程屬於額外工作，則應在定義中作明確區分。

4. 當 Sprint 期間出現重要且有時限的臨時項目影響原有工作時，可利用需求梳理會議（Backlog Refinement）及預留緩衝容量來調整人力和任務優先順序，並與利益關係人進行及時溝通，以確保團隊能夠靈活應對並保證交付成果。

5. 若部分工作項目因依賴性和循序性必須跨越不同 Sprint 完成，如前一個 Sprint 的成果必須依賴後一個才能發揮效用，則需在任務拆解時進行調整，確保每個 Sprint 都能產出獨立有用的結果；若無法完全避免此情形，則需在團隊與相關人員間達成共識，並在回顧會中檢討如何改善拆分方式，以更符合敏捷「完成定義」標準。

此外，文章也強調透過故事地圖、優先級評估（涵蓋商業價值、用戶需求、技術可行性與依賴性）等工具，能夠幫助團隊聚焦於實現最小可行產品（MVP）最核心的功能，從而更合理地安排上線計劃並提升整體專案成功率。