什麼是敏捷管理法？ (新手指南)

Scrum、看板、瀑布、敏捷法。 

有許多專案管理架構可供選擇，但像瀑布式這類傳統方法對軟體團隊來說並不總是有效，因為優先事項和客戶需求經常發生變化。 另一方面，敏捷方法將專案分解為較小的階段，以便團隊可以隨時進行調整並持續改進。 雖然敏捷專案管理在軟體開發中很受歡迎，但不同行業的團隊也成功地使用了它。 如果您想瞭解敏捷法的運作方式，並決定它是否適合您的團隊，那麼您來對地方了。

什麼是敏捷管理法？

敏捷方法是一種專案管理方式，它將工作分解成小型、可管理的週期，通常稱為衝刺。 這是一個疊代流程，團隊會為每次衝刺設定目標，然後與專案關係人一起建立、測試和審查他們的工作，再進入下一次衝刺。 每次衝刺後，團隊都會進行反思和回顧，看看是否有任何可以改進的地方。 定期回饋有助於團隊適應變化、更快交付成果，並更好地滿足客戶需求。

每個團隊都應該知道的敏捷概念

• 敏捷：一種專案管理方法，以小幅度漸增的方式交付高品質的工作，而非一次性最終發佈。

• 衝刺：一個短暫的工作週期，通常為一到四週，團隊承諾在此期間完成特定任務。

• 待辦項目：指導團隊下一步工作的功能、修復和任務的優先順序清單。

• 衝刺待辦項目：團隊計劃在衝刺期間完成的產品待辦項目中的選定項目。

• 站立會議：團隊成員分享進度、計劃和阻礙的簡短每日會議。

• 迭代：規劃、構建、測試和審查工作的重複週期，以改善結果。

• 使用者故事：從終端使用者的角度對功能進行簡介，通常用於定義需求。

• 史詩：由多個使用者故事組成的大型工作項目，跨越多個衝刺。

• 速度：顯示團隊在衝刺中已完成工作量的指標，通常以故事點衡量。

• 燃燒圖：一種可視化工具，用於追蹤衝刺或專案中剩餘工作與剩餘時間的對比。

• 進行中 (WIP) ：目前正在進行的任務；限制 WIP 有助於防止瓶頸和延遲。

什麼是敏捷宣言？

敏捷軟體開發宣言是一份文件，詳細資料了敏捷軟體開發的四項價值觀和十二點原則。 該宣言由 17 位軟體開發者於 2001 年 2 月發佈，他們需要一套取代偏線性產品開發流程的方法。 它優先考慮人員、工作解決方案、客戶協作以及應對變化的能力，而不是僵化的計劃、繁重的文件和嚴格的流程。 這些價值觀塑造了敏捷團隊的工作方式、決策方式和衡量進度的方式。

敏捷法的四大支柱是什麼？

如敏捷宣言中所述，敏捷專案管理法有四項主要原則：

1. 對人的重視勝於流程和工具。 敏捷法團隊重視團隊協作與合作，而非獨立工作和「照章行事」。

2. 對軟體功能的重視勝過完整的文件。 敏捷團隊開發的軟體應該能夠運作。其他工作，如文件記錄，不如開發優質軟體那麼重要。

3. 以客戶協作為重，而非合約協商。客戶在敏捷管理法中極為重要。敏捷團隊允許客戶指導軟體的開發方向。因此，客戶協作比合約協商的細節更為重要。

4. 應對變化勝過遵循計劃。 敏捷專案管理法的其中一個重要好處是其靈活性。 敏捷使團隊能夠快速改變策略和工作流程，而不會使整個專案脫軌。

敏捷法的 12 項原則是什麼？

若敏捷模型的四個價值觀是房屋的承重柱，那麼敏捷法的 12 項原則就是房屋內可以打造的房間。 這些原則可以輕易調整，以滿足您的軟體開發流程需求。 

敏捷方法中使用的 12 個原則是：

1. 透過早期、持續的改進和交付來滿足客戶。 當客戶定期收到更新時，他們更有可能在產品中看到他們想要的變更。 這能讓客戶更開心、更滿意，也能帶來更多經常性收入。

2. 歡迎客戶變更需求，即使在專案的後期也是如此。 適應性是敏捷架構的重點。在像敏捷法這樣的疊代方法中，缺乏靈活性會導致弊大於利。

3. 頻繁實現價值。 與原則 #1 類似，持續為客戶或關係人提供價值，通常能降低流失客戶的機會。 

4. 突破專案的孤島。 跨職能團隊和協作是敏捷法的一項關鍵價值。 其目標是讓人擺脫個人專案，並更頻繁地協作。 

5. 以有動力的個人為中心建立專案。當團隊全心投入並積極努力實現目標時，敏捷管理就能發揮最佳效果。

6. 最有效的溝通方式是面對面的交流。 如果您是在分散式團隊中工作，請花時間以包含面對面的方式進行溝通，例如 Zoom 通話或每日的站立會議。 

7. 工作軟體是衡量進度的主要指標。 軟體開發專案的最終目標是一個可以運作的產品，而敏捷法架構則會優先考慮軟體運作來支持此目標。

8. 保持可持續的工作步調。 敏捷專案管理法在某些方面可能步調很快，但不應該太快，以免讓團隊成員感到疲憊不堪。 目標是在整個開發過程中保持可持續性。

9. 持續的卓越表現才能提升敏捷度。 如果團隊在一個衝刺中開發出優秀的程式碼，他們可以在下一個衝刺中以此為基礎繼續開發。 持續打造出色的工作，可提升團隊在未來的推進速度。 

10. 保持簡單是重點。有時候，最簡單的解決方案就是最佳的解決方案。敏捷開發的目標是不要把事情變得過度複雜，並為複雜的問題找到簡單的答案。

11. 自我組織的團隊能創造最大價值。 與原則 #5 類似，積極主動的團隊會成為公司的寶貴資產，因為他們會努力持續改進。

12. 定期反思並調整您的工作方式，提高效率。 回顧會議是一種常見的敏捷開發做法。 這是敏捷團隊專門用於反思其績效，並針對未來調整行為的時間。

敏捷開發法有哪些優勢？

敏捷專案管理法為優先順序和需求經常變動的專案提供了優勢。 與線性專案管理方法不同，敏捷法允許持續迭代，因此非常適合功能快速變化的應用程式和軟體開發。

敏捷方法具有適應性

敏捷開發使團隊能夠調整計劃，而不會中斷整個專案。 與瀑布模式不同的是，敏捷流程並不會將每個階段嚴格地與前一個階段綁定，因此變更不會影響整體專案藍圖。 這種結構有助於團隊更快地應對不斷變化的需求和客戶回饋。

敏捷法能夠促進團隊協作

敏捷方法鼓勵團隊之間的直接溝通，並旨在消除角色之間的障礙。 它強調面對面討論和共同責任，從而改善合作並減少誤解。 即使使用遠距工作和現代化工具，敏捷方法仍會繼續優先考慮積極溝通，以加強團隊合作。

敏捷方法專注於客戶需求

敏捷團隊在快速、持續的回饋中茁壯成長。 隨著產品的開發，終端使用者會分享他們的需求，團隊會相應地更新優先順序。 這種回饋迴圈可提高客戶滿意度，因為改進是基於實際測試驅動的開發，而非假設。

8 種敏捷管理法類型

敏捷架構包含幾種變化型。 以下是八種最常見的敏捷方法。 

1. 看板

看板是一種視覺化的敏捷法。 團隊使用線上工作流程看板來呈現進行中的工作，任務會在每個開發階段中移動。 任務在看板上以卡片的形式顯示，階段以欄的形式顯示，團隊成員將每張卡片從待辦項目移動到與其目前階段相應的欄中。 看板是一種有用的策略，可用於識別障礙並追蹤已完成的工作量。

2. Scrum

Scrum是小型團隊使用的常見敏捷法，也包含衝刺。 團隊由 Scrum 主持人帶領，其主要工作是為其他人執行日常工作清除所有障礙。 Scrum 團隊每天召開會議，討論進行中的任務、障礙以及其他可能影響開發流程的問題。

• 衝刺規劃：此活動將啟動衝刺。 衝刺規劃概述了衝刺中可以交付的內容 (以及交付方式)。

• 衝刺回顧：這個定期舉行的會議可視為衝刺審查，以便反覆利用先前衝刺的經驗教訓，從而改進並簡化下一次衝刺。 

3. 極限編程 (XP)

極限編程 (XP)是一種用於軟體開發的敏捷架構，強調團隊價值觀以改善協作。 其五個核心價值觀 (溝通、簡單、回饋、勇氣和尊重) 指導開發人員在整個專案中如何互動和做出決策。 與 Scrum 每日站立會議類似，XP 也涉及頻繁的發佈和疊代。 它採用更具技術性的方法，專注於工作的完成方式，以便開發團隊能夠快速響應客戶需求。

4. 適應式專案架構 (APF)

適應性專案架構認識到專案的任何階段都可能出現未知因素，因此非常適合傳統方法不足的IT 專案。 APF 並非假設條件穩定，而是認識到預算、時間軸和團隊組成可能會發生變化，並相應地修改計劃。 此方法強調利用專案目前擁有的資源，而非最初計劃所需的資源。

5. 極限專案管理 (XPM)

極限專案管理是為不確定性高的複雜專案而設計的，其中變化是持續的，固定計劃很少成功。 團隊不斷調整其方法，根據需要切換策略，並使用試誤法，直到取得期望的結果。 由於彈性至關重要，衝刺是簡介和疊代的，團隊可以在整個過程中重新審視決策、測試想法和自我修正。

6. 適應性軟體開發 (ASD)

適應性軟體開發是一種敏捷方法，專為需要隨著需求變化而調整計劃的團隊而設計。 ASD 不是遵循固定的專案藍圖，而是循環經歷三個重疊的階段(推測、協作和學習)，這些階段可以同時進行。 這種結構鼓勵持續實驗、持續學習和快速解決問題。 與傳統的專案管理方法相比，這些特質有助於團隊更快地識別問題，並更有效地進行調整。

7. 動態系統開發方法 (DSDM)

動態系統開發方法是一種專注於完整專案生命週期的敏捷方法。 正因如此，DSDM 與其他敏捷方法不同，其結構和基礎更加嚴格。

DSDM 有四個主要階段：

• 可行性和業務研究

• 功能模式或原型疊代

• 設計和建構疊代

• 實施

8. 功能驅動開發 (FDD)

功能驅動開發結合了敏捷最佳做法，重點是構建和交付特定的軟體功能。 這種迭代方法依賴於客戶的意見來決定優先考慮哪些功能，從而使開發與實際需求和期望保持一致。 由於團隊經常更新專案，因此他們可以快速識別錯誤並實施修復，而不會減緩專案的進度。

使用 Asana 組織敏捷流程

您經常會聽到軟體開發團隊提到敏捷流程，但任何團隊都可以運用敏捷法。 若您正在尋找更靈活的專案管理架構，請嘗試 Agile。 

常見問答：敏捷法含義和最佳作法