本文節選自《敏捷實戰：破解敏捷落地的60個難題》

有剛接觸敏捷的朋友問：「有些基本概念不是很清楚，問敏捷、精益、六西格瑪、PMP 等方法論之間的有什麼差異？」

這是一個很好的問題，很多想要了解敏捷的 PM 或開發者經常以不同形式提到類似的問題。

儘管並非總會問到上面列舉的所有方法論，有時會提到 Scrum、軟體開發生命週期(software development lifecycle，SDLC) 等，但這個問題一定少不了。

首先應該明確「方法論」和「框架」這兩個概念之間的差別，然後再討論具體方法。

「方法論」是由各種方法、工具和實踐構成的系統，明確勾畫出了各個階段，以及每個環節需要 做的工作。

「框架」定義了一些基本實踐和模式，但是允許在執行這些實踐和模式時適當調整。

01

敏捷

Agile

敏捷本身既不是方法論，也不是框架，而是一套價值觀和原則。反映了關於價值交付的一種哲學和思考方式。

由於「敏捷宣言」的提出者屬於他們那個時代的先驅，各自都在探索不同的軟體開發實踐，因此敏捷代表了許多方法的總和，而不是特定方法。

敏捷更像一個概括性術語，它定義了 Scrum、極限程式設計、看板方法、自適應軟體開發、快速應用程式開發等方法的共同宗旨，從信念和精神的層面描述了這些實踐目標的共同點。

02

精益

Lean

精益和敏捷的共同點是通過減少浪費來交付價值的。

就某些方面而言，精益和敏捷幾乎是一回事，但精益也有一些特定元素。

例如下面這 5 條原則:

(1) 識別價值;

(2) 分析價值流;

(3) 創造流動;

(4) 構建拉動式系統;

(5) 追求完美。

精益還識別出了在任何生產過程中都可能存在的 7 種浪費，無論生產型別如何，都包括:

(1) 搬運;

(2) 庫存;

(3) 動作;

(4) 等待;

(5) 生產過剩;

(6) 過度加工;

(7) 缺陷。

我們需要在考慮外部依賴約束的情況下，尋找減少甚至避免這些浪費的方法。也就是說，系統會受到不可控問題的影響，所以應該對系統性能而不是區域性效能進行優化，因為區域性效能的提升不一定會導致總吞吐量增加。

因此，這不是一個“使用 Scrum 還是......”或者“使用極限程式設計還是......”的問題。這些方法之間並非完全互斥，其中很多實踐是相通的，即使是不同的實踐，從更大的範圍來看也是互補或相容的。

03

六西格瑪

Six Sigma

六西格瑪(Six Sigma，6σ)是一組實踐和工具，但更注重通過度量和指標來實現優化，而 不是通過有機的反饋迴圈。

六西格瑪的核心就是精益的總體目標：減少浪費，將價值最大化。

然而，由於六西格瑪強調定量和定性的度量，因此許多敏捷倡導者認為六西格瑪過於笨重，甚至在應用中有些差錯。

但是對於受到嚴格法規要求的行業來說，六西格瑪為企業的轉變和優化提供了理由。

對於不會對人身安全和公共福利構成極大風險或威脅的軟體系統來說，優化效能和調整目標更多是由與顧客互動而不是指標檢測來驅動的。

看板方法是一個框架，通過從頭至尾追蹤每項工作的狀態，提高工作流(系統)中工作的透明度。其關鍵特性是，每個工作流狀態都有一個相應的「進行中工作」(work in progress，WIP) 數量上限，從而將整個工作流從一個推動式系統變成一個拉動式系統。

在推動式系統中，可以將工作持續向工作流下游傳送，不必擔心瓶頸或溢位問題。在拉動式系統中，在下游的工作流狀態出現空位之前，新增工作都不能在工作流中推進。

唯一的例外是，在出現緊急工作的罕見情況下，可以使用快速佇列來突破「進行中工作」數量上限。

04

看板+Scrum

Kanban + Scrum

看板方法可以與 Scrum 結合使用並取得一定的成功，尤其是在開發團隊專注於建立一個符合「完成的定義」(definition of done)的連貫特性流，並且該特性流是通過持續部署而不是批量部署來得到可釋出產品增量的情況下。

Scrum 的作用在於，Scrum 儀式(活動)可以提供優化機制(反饋迴圈)，例如團隊成員可以定期審視團隊的成長和成績，並討論團隊工作的優化方式。這就是

Scrum 中「衝刺回顧會議」的概念。團隊還可以定期反思產品，以確保產品符合顧客和利益相關者的預期，這就是 Scrum 中「衝刺評審會議」的概念。

相比 Scrum，極限程式設計更偏向工程實踐而不是角色形式。這些工程實踐包括持續整合、測試驅動開發、結對程式設計、驗收標準的採用、程式碼重構，以及程式碼共有，等等。

05

專案管理

Project Management

還有其他一些實踐組合，例如快速應用開發、動態系統開發方法(dynamic systems development method，DSDM)和 Crystal Clear 等，都影響並啟發了「敏捷宣言」。

甚至統一軟體開發過程(rational unified process，RUP)的某些方面、「The New, New Product Development Game」(Takeuchi 和 Nonaka 於 1986 年發表)一文，以及傳統專案管理的某些部分，都對敏捷有所影響。

也就是說，雖然沒有明確提及專案管理，但是用於「管理專案」的活動會自然而然地出現在敏捷的各種實踐過程中。

更重要的是，企業需要建立一種文化，將變化、學習、人文關懷、負責任的成長、好奇心、實驗、娛樂以及餘量(見 Andy Stanley 的 Take It to the Limit 一書)看作可持續的開發節奏和關鍵動態，致力於提高顧客和員工的生活質量並造福世界。

主動學習、提倡思想自由交流而無懼負面影響的企業，擅長創造讓顧客滿意的創新產品。

按照 Steve Denning 的 《The Leader’s Guide to Radical Management》一書中的說法，唯一重要的事情就是致力於讓顧客滿意，而這可以通過持續創新來實現。

Steve Denning 的結論是，對利潤、成本和股東價值的關注並不能帶來預期的利潤增長，但如果專注於交付讓顧客滿意的產品，利潤自然會隨之而來。

Daniel James Gullo |著

倪琛| 譯

敏捷對於軟體開發，乃至更廣泛意義上的企業運作和專案管理都很有指導意義，但成功地在企業內實踐敏捷並非易事。

本書詳細探討了敏捷之路上最常遇到的問題，旨在幫助讀者掃清敏捷實踐路上的種種障礙。

本書主要內容包括：敏捷的真實含義和相關概念，從瀑布式開發模式向敏捷開發轉型時的常見問題，Scrum 的使用方法，顧客需求分析，產品負責人和專案經理的角色定位，團隊組織方式，敏捷相關會議，敏捷社群經驗分享，等等。

圖靈官方小店

享受正版低價折扣