破解敏捷專案管理

雖然敏捷方法使人們擺脫了在愚蠢決策上投資過多的恐懼，但應用起來可能相當混亂。

在這篇文章中，您將學到：

• Scrum和Kanban看板之間的差異

• 逐步指導如何在團隊中設立敏捷實踐

• 避免每個步驟中的陷阱的建議。

敏捷專案管理不同於傳統方法，強調短期回饋迴路和適應性週期。通過不斷地發布增量，支持者相信敏捷過程更能適應客戶價值和需求。

它首次於1990年代引入，以取代繁重的瀑布方法學。它提倡持續改進。2000年代初期見證了敏捷方法的一個里程碑。十位著名從業者，包括Jeff Sutherland，共同提出了著名的敏捷軟體開發宣言。

自那時以來，許多變體已經發展。Scrum、極限編程（XP）、特徵驅動開發（FDD），以及測試驅動開發（TDD）只是其中的一小部分。然而，無論名稱如何，基本原則始終不變——>通過迭代開發、縮短回饋迴路和適應性規劃來降低業務風險。

在所有這些框架中，Scrum 是最受歡迎的。完整週期包括五個階段：構想、短衝規劃會議、每日短衝、發布及回顧。本篇文章將重點介紹Scrum框架。

但首先，...

Scrum和Kanban之間有什麼區別

在指導之前，讓我們釐清兩個常用術語：

Scrum 是一種框架、一個過程

一種設計給小型團隊的敏捷框架，用於將工作拆分為可在限時迭代內完成的動作，稱為短衝，通常為兩週。團隊在15分鐘的站立會議中跟蹤進度並重新規劃，稱為每日Scrum。

Kanban 是任務的可視化方法

一種精益方法，用於管理和改善工作，通過將工作項目可視化給予參加者對需求和可用容量的概覽。這些可視化項目的集合稱為Kanban看板。在Scrum中也使用了此看板。

Kanban和Scrum是兩種方法。但由於Kanban看板的普遍和有效性，Scrum框架有時也採用此工具。除了上述術語，您還可以在AgileAlliance檢查更多敏捷術語表。

如何設立敏捷實踐

步驟1：準備 - 建立您的團隊

通常一個敏捷團隊由三個角色組成：Scrum Master (SM)，產品負責人 (PO) 和開發者。團隊規模約為7(+/-2)：1位Scrum Master，1位產品負責人，和3-5位開發者。

Scrum Master站在開發者一方，確保專案順利進行，並希望更快。TA應該是一個獨立角色的調解者或促進者。然而，根據團隊的興趣，技術領導或QA可以很好的作為兼職Scrum Master。

產品負責人位於專案和用戶一方。他們是商務人士和客戶代表。因此，產品負責人通常是產品管理者或行銷人員。

最佳實踐：避免嚴重衝突

合作但不競爭。

Scrum Master和產品負責人有不同的重點，可能會進入嚴重衝突。但請記住，團隊工作應該協作完成所有工作。設立三個角色的意義在於使團隊全功能化。因此，團隊內的每個人一起計畫。

步驟2：構想 - 準備產品待辦清單

產品負責人是這個階段的主要貢獻者。TA與利害關係人交談，並綜合出產品功能待辦清單。利害關係人通常包括高層、銷售和支援團隊、行銷團隊、用戶或客戶。

PO必須修整待辦清單並優先安排功能。而從這個龐大的待辦清單中，TA表達願景和後續目標。

最佳實踐：避免繁瑣

自動化繁重過程。

填充產品待辦清單有時是一件繁瑣的工作。收集和追蹤過程可能高度重複。對於錯誤修復，PO可以將待辦清單與錯誤追蹤系統聯繫起來。評論追蹤工具和社群媒體管理平台也很有幫助。

步驟3：會議 - 舉行短衝規劃會議

會議提出清晰的短衝目標和短衝待辦事項。通常為期不到一小時，並在短衝週的早期發生。基於產品目標和產品待辦清單，團隊一起工作將待辦事項拆分為可交付增量。

開發者決定合適的故事點數量、將目標分解為任務的方式，從而形成短衝待辦清單。會議結束時，團隊應對本次短衝的範圍和期望的交付品有信心。

最佳實踐：避免模糊目標

明確短衝交付品的期望。

短衝目標不僅僅是隨機的一兩句話，而是給予利害關係者對交付品的期望。它作為給利害關係者的快速報告指明團隊正在做什麼。一個明確的短衝目標為衡量交付表現鋪平道路。

步驟4：每日Scrum - 持續檢查

每日Scrum（每日站立）會議是為了項目狀態更新。最好在每次迭代中以相同的時間和地點安排每天的會議。每日站立展示了敏捷對面對面交流的重視。

Scrum Master應該解決障礙以促進開發過程。如果有任何嚴重影響短衝目標的事物，PO有權立即知道。同時，PO需要抑制更改短衝待辦清單的誘惑。

最佳實踐：避免冗長會議

將每次站立會議控制在15分鐘內。請注意，會議更像是團隊內的信息同步，而不是問題解決。最好將問題解決留給其他過程。

步驟5：發佈 - 發佈及回顧

團隊的發佈在迭代結束時展示。利害關係者，無論在組織內外，都會參加評審會議。通過比較整體短衝目標與成就，產品負責人可以衡量短衝的成敗。

在評審會議之後，敏捷團隊主持一次回顧會議以反思哪些應該改進和繼續。對於新手開發者來說，這也是一個檢討速度和容量期望的絕佳機會。

最佳實踐：永遠不要跳過回顧

即使沒有出現問題，團隊也不應跳過回顧。僅確認正確之處對未來的短衝就有幫助。如果SM想要，TA甚至可以為改進提案啟動投票。

敏捷的限制有哪些

支持者聲稱敏捷實踐是在微觀管理和無管理之間的平衡。然而，批評聲從採用經驗中產生。一些經驗研究發現對團隊敏捷性沒有科學證據。

由於敏捷強調靈活性，它對持續品質控制帶來負擔。縮短的專案長度意味著快速和精益行動。而這常常伴隨著缺乏適當的文件和資源。專案往往缺乏連續性和完整性，使得質量關注的原則幾近過時。

敏捷並不適合高度偏好風險回避的組織或行業，例如製藥業。這些歷史悠久的行業有它們笨重但重要的慣例要遵循。改變程序違反傳統管理極其冒險，甚至危險。

儘管如此，無數的成功案例證明了敏捷的有效性。即使存在陷阱，持續演進的敏捷框架提供了工具和技術，例如持續集成（CI/CD）、自動化單元測試和代碼重構，以至少彌補這些問題。

關鍵總結

敏捷過程倡導快速迭代、持續改進和快速應對變化。主要包括五個步驟：構想、短衝規劃、每日Scrum、發佈和回顧。

此方法旨在平衡傳統方法與鬆散管理之間的關係。儘管缺乏強有力的證據且存在陷阱，敏捷過程有其自身成功的理由。

您有什麼意見嗎？在推特上告訴我，分享您在應用敏捷方法中的經驗和技巧 :)