在比較出名的敏捷框架中，Scrum 和 XP 的大名想必不用我說，大家也略知一二。但是，既然是系統的理論方向的系列文章，同時也肩負著為一些第一次接觸敏捷的同學進行科普的重任，我們還是需要一個一個的來說說各種不同的敏捷框架。當然，最重要的兩個敏捷框架，我們也會在敏捷框架這一章中穿插著進行學習。

首先我們要學習的內容，其實在嚴格意義上來說，並不屬於敏捷框架的範疇。但是，它們又是所有敏捷框架，甚至是敏捷概念的起源。同時，它也是一系列的實踐和方法論的集合，又有著框架的影子。高大上不？激動人心不？趕緊走起吧！

敏捷的起源

說到敏捷的起源，總會有不少文章提到那幾個人和那個算是第一次的敏捷大會。在那次會議上，有了敏捷宣言和原則。沒錯，那次大會確實是敏捷的誕生大會，這一點是無可辯駁的。不過，我們這裡要追溯的，是在敏捷概念的誕生有沒有借鑑誰。

說到 “借鑑” 這個詞。不好聽點就是 “抄” ，好聽點就是原來流行過一段時間的 “微創新” 。敏捷是誕生於軟體開發行業，所以它吸收了傳統瀑布流開發的許多經驗，這是無可厚非的。同時，它又是一種專案管理的經驗，所以傳統專案管理中的一些內容也會體現在敏捷中。

但是，真正讓敏捷成為敏捷的，反而不是軟體行業中出現的什麼管理變革。傳統行業中，豐田生產線上的 “精益生產管理” 才是真正影響敏捷的，並且讓敏捷真正敏捷起來的重要影響因素。

精益方法

是的，你沒看錯，精益方法確實就是起源於豐田生產線上，是正宗的傳統制造業中產能管理的偉大創新。當敏捷先驅們看到它的時候，感覺這東西用在軟體開發中也是相當不違和甚至是有許多好處的。這時，基於精益的理念就出現在了軟體行業中，進而一步步地影響著敏捷先驅們，直到真正的敏捷宣言的誕生。

精益生產有一個最大的特點，那就是要消除浪費。這是源於汽車裝配業的成本問題，拼裝一輛汽車需要的零件有多少？需要的人工有多少？庫存需要準備多少？消除浪費就是用最少的庫存，最少的人力成本，實現最大的量產規模。對應到精益中，就需要 準時生產製 、 全員改善 。

準時生產，就是一個團隊負責一個單元，注意，一個小團隊。然後改善呢？就是每一次的任務之後所有全部的員工都會參與到建議系統中，進行持續不斷地對業務流程和製作工藝的改善。小團隊、任務（迭代、增量）、改善（回顧、持續整合），是不是有那麼點敏捷的味道了？

我們先來看看一個普通企業可能在生產管理過程中帶來的浪費和各種問題。它包括七種主要的浪費形式：過量生產、等待、運輸、過度流程、庫存、再作業和情緒。在這中間，包括 WIP 在製品、價值流圖、拉動系統等也都是敏捷中的常用術語。特別是 WIP 在製品的概念，正在製作中的產品就是在製品，而減少 WIP 的數量，就是在消除浪費，在製品數量越多，上面的七種浪費也就越多越不可控。

精益提供的一系列方法，就是針對上述的這些浪費而來的。也是精益的核心操作方法。

精益方法在敏捷中的應用

前文說過，精益不完全算是一種敏捷框架，但是，這不妨礙你在敏捷專案開發中遵循精益的一些理念。甚至說，你完全也可以將它視做是一個敏捷框架，而且是最簡單的一種敏捷框架，只需要你理解下面這七點：

1.消除浪費

沒錯，第一個就是最核心的概念，我們要把浪費給消除掉。多餘的會議、規劃、文件、測試或某項功能，如果不做的話會不會也能取得我們想要的結果？如果答案是“是”的話，毫不猶豫地消除它。這也可以表現為一個名詞，就是 JIT ，Just In Time ，在需要的時候，按需要的量生產所需的產品，沒有一絲的浪費。

2.儘早交付

儘早交付，交付的是什麼呢？不一定是一個完整的產品，當然，如果是傳統制造業，就是要儘早地交付一個產品。但是在軟體業，我們可以儘早交付部分功能，而不是整個專案。好吧，軟體開發中的“持續整合”就是這個概念的衍生品，最好的儘快交付是什麼？就是我們每次程式碼的提交，都能完成一次構建，都能馬上讓使用者體驗到這個新的功能，都能最快速地獲得反饋。

3.強化學習

精益追求的是不斷地、快速地學習和改進。無論你的團隊有多強大，總會有可以改進的地方，所以當看到 Kaizen 這個單詞時不要驚訝，它是日語 持續改進 的意思。那麼如何改進呢？學習，積累知識，吸取經驗教訓，沒別的方法。

4.團隊授權

關於敏捷團隊的問題，上篇文章中已經詳細說明了。看到了嗎？早在精益生產時期，在流水線上，給團隊授權就已經出現了。

5.推遲決策

越早決策，就是越早決定我們要走哪條路。但問題是，往往在路口的時候我們才會清晰地知道我們要走哪條路。專案開發不是一次地圖導航，即使是地圖導航，在大資料的演算法下，也會實時為我們更新更好的路線。所以，讓決策來得晚一些，讓團隊有更多的選擇。但，決策也不能太晚，有些東西錯過了就是一生的遺憾，如何把握，這是門大學問。提示一點，參考團隊的意見。

6.整體優化

在對區域性優化的時候，往往也會影響到整個價值流。區域性的優化，如果不能帶來整體的效益，那麼這個優化就是沒有價值的。什麼意思呢？程式碼模組的重構是有成本的，哪裡的重構最重要？當然是最能影響整體的那部分。流水線上的產品，任何一個部分有優化，都有可能帶來整個流水線效率的質的提升，如果不能帶來這樣的提升，那麼不如不做。

7.全盤檢視

團隊是一個整體，整體建立的解決方案也應該是在全域性的、完整的解決方案之上的。我們不能只盯著技術那一塊，還要了解市場、商業、規範，甚至是人事調動、行政支援等等一系列的，與專案相關的內容。

看板

看板，英文名是 Kanban ，我去，你沒看錯，不過不是我們的拼音，是日文看板的英語發音。沒錯，這玩意跟精益是一個體系的，就是放在豐田那條生產線邊上的一塊白板。雖說就是一塊簡單的白板，但是它對敏捷的影響力可是非常恐怖的。比如說我們現在常用的一些專案管理軟體，Worktile、Teambition、Tower、Jira，甚至國產的禪道、釘釘的任務管家、騰訊的TAPD，只要說它是支援敏捷的專案管理軟體，那麼一定就有看板功能。是不是非常恐怖？

那麼真正的精益看板是什麼樣的呢？

沒錯，看板就是使用一個大白板，而且在生產車間可能還會立著許多這樣的白板。圖中的每一塊可能就是通過一個單獨看板來展示的。標準的看板使用的是一種拉動系統，通過卡片表示出工序何時需要何數量，這其實就是限制 WIP 流動的一種思想以及 JIT 思想的載體。卡片沿著工序流動，不停地向下向後傳遞，直到這個零件或者元件製造完成，卡片就被取下放入到看板盒中。

綜上所述，看板有著 管理流動 的能力，這是看板非常核心的功能。除此之外，我們還可以將任務的進度、耗費的資源也體現在一張白板上，比如我們後面要學習到的燃起圖、燃盡圖等等。這就出現了看板的第二個能力，它可以 度量 我們的專案。

在看板管理的不斷髮展過程中，又現出了單獨的一些管理看板。比如說質量控制看板、訊號看板、任務看板等。在軟體領域，主要的就是任務看板。

比如我在實際的專案開發過程中，使用過的 Scrum 任務板。這個東西具體的內容我們將在 Scrum 相關的文章再詳細的說明。

看板方法的核心實踐

看板對於敏捷的影響夠大吧？許多的敏捷著作都會提到一個問題，那就是到底是使用實物白板來當做團隊的看板還是使用電子看板呢？其實各類教材都會回答你，條件允許的話，請在辦公室放置足夠多的實物白板，甚至是牆壁上貼上白紙，或者隔間的玻璃，都可以當做白板。為什麼呢？因為白板要帶來的最大效果是視覺化的工作流。

每個人，都可以在經過白板時不經意的看一眼白板上的內容，而很多有趣的事情，也很有可能就此發生。對於看板來說，這是一種 協同改進 的能力。讓專案的所有資訊公開、透明，讓團隊之間沒有祕密，是敏捷的一個崇高理想。

通過上面的學習分析，我們其實就可以得出看板的五個核心實踐：

1. 視覺化工作

2. 限制在製品數量

3. 度量和管理流動

4. 協同改進

5. 顯式化流程規則

也可以說，這五個方面是看板的最大的優點，也是在所有敏捷軟體中，看板功能如此盛行的原因。這下是不是理解這些軟體背後設計的意義了。現在你還覺得這些看板功能只是一個記錄 BUG 的工具嗎？（我經歷過的團隊有些就是把這種工具當成 BUG 記錄工具的）

總結

今天通過精益和看板，正式進入了敏捷框架的學習。其實就像文章中一直說的，這兩個東西即是敏捷的一部分，又是敏捷的先祖之一，在各類敏捷實踐中都佔據著非常重要的位置。後面我們學習到的很多內容，其實都有精益的影子，所以我們把這部分內容放到最前面來，也是希望大家有個提前的預習。

下一篇文章，我們簡單瞭解一下 極限程式設計 ，也就是大家口頭上經常說的 XP ，到底這貨有多極限呢？別急，一步一步來。

參考文件：

《某培訓機構教材》

《使用者故事與敏捷方法》

《高效通過PMI-ACP考試（第2版）》

《敏捷專案管理與PMI-ACP應試指南》