項目管理 實作靈活架構的比較：Scrum 方法 vs 看闆方法 vs 精益開發 vs 極限程式設計

本文中，我們會講解時下最流行的四種實作靈活開發的架構方法，并且一一列舉他們的優缺點。

如果您是剛剛踏進靈活開發的世界中，可能剛開始會被這個方法那個方法搞暈掉。那是因為靈活開發隻是一些簡明扼要的概要準則，沒有明确說明需要如何一二三步驟地來落地實作。

是以，人們從實踐中總結真知，就衍生出了實作靈活的各種各樣的方法。其中，最廣為人知的當屬 Scrum 方法、看闆方法、精益開發以及極限程式設計。

雖然本文主旨是要對比上述的四種方法，不過要是較真地來分析他們的不同，實際感覺上就好比要比較蘋果和橘子的不同有哪些。因為他們其中有的就是從另一種方法衍生而來或者是另一種方法的補充罷了（尤其是當這些方法被應用在開發環節的不同周期中，更難去比較他們之間的不同）

一、Scrum 方法

Scrum 方法可以稱作是靈活在軟體開發中的實作架構。前不久，我遇見了自己上一份工作的同僚們時會都告訴他們我正在我的新崗位做靈活開發。這些同僚第一反應就會問我，“是嗎，那你們是不是每天都會開站會，是不是每天都要有成果物傳遞呢？”在大多數人眼中，Scrum 方法就是靈活開發的同義詞。

當然首先，Scrum 方法是一個管理上的理論架構。它闡述的是軟體開發人員們沒有在敲代碼時應該都幹些啥。Scrum 方法明确地規定了一個模型，根據這個模型，軟體開發人員們可以安排他們的開發計劃，并持續疊代更新這個計劃，以及定時回顧分析之前的開發過程中發生的事情。

在這個架構中包含一個叫 Scrum Master 的角色，擔任這個角色的人要專注于把控項目的進度并竭盡可能輔助程式員們開發作業。

實操方法

Scrum 中，每個階段傳遞資訊用到的産物主要有：

• 1、User Story（使用者故事）。使用者故事闡述的是一個小的功能點，團隊成員們要在特定的時間段内完成這個功能的開發作業，而這個特定的時間段，被稱作為沖刺計劃。 使用者故事的通常格式是，作為一個….（使用者角色），我想要…..（軟體應該實作的這種那種的功能），這樣我就可以……（如何如何，最終實作一個實際業務中的效果）。 每個使用者故事都要有個結束要傳遞的成果物，這個成果物會被先用來判斷這個使用者故事是否完整準确表達了客戶的實際需求。
• 2、Task（任務）。任務可以跟使用者故事挂鈎，當然不做關聯也可以。就例如給電腦搭一套新的開發環境，或者去研究機器 cpu 記憶體的事宜，這些任務就沒必要跟使用者故事扯上關系。
• 3、Backlog（清單）。好些個用于未來沖刺計劃的使用者故事和任務組成的清單就是Backlog。
• 4、Sprint backlog（沖刺清單）。從Backlog中抽取的幾個用于本次沖刺計劃的使用者故事和任務(或者稱作待辦事項)集合成的清單。
• 5、Product increment（疊代成果）。每次沖刺計劃後形成的可以傳遞的成果物。
• 6、Extensions（文檔表格）。像燃盡圖，流程圖之類的，用于把控團隊流程的文檔。

角色有哪些

• 1、Development Team.（開發成員組）這個小組中包含了測試，前端開發，需求分析師，等等所有疊代開發程式需要的人員。Scrum 的成員基本上會控制在3-9人。假如說人員擴充超過了9人限制，就需要将團隊一分為二。
• 2、Scrum Master（靈活專家），SM 們需要主持召開每日的站會，以及開發前的計劃會議、開發中的梳理流程會議、開發後的回顧總結會議，還有個重任是要幫助團隊成員們解決所有關系到溝通的事宜。SM 不是開發小組的成員，是以多個靈活小組可以同時共享一名Scrum Master。
• 3、Product Owner（産品經理），站在客戶的立場，用客戶的眼光（這樣的視角可以更貼近現實情況地編寫使用者故事）來幫助靈活團隊開發，PO 的工作還包括評定使用者故事的優先次序，并在每次沖擊計劃完成後評估傳遞的成果物是否符合要求。

價值點：

• 1、目标性明确（完成每一次的沖刺計劃）
• 2、有勇氣（敢于做大家一緻認同正确的決定）
• 3、有專注度（每次的疊代隻專注一個事項）
• 4、開放性（積極面對各種各樣的挑戰）
• 5、互相信賴（彼此相信都在用盡自己最大的努力做事情）

二、看闆方法

看闆方法是由一位豐田公司叫大野耐一的工程師建立的（譯者注：現代軟體看闆之父為 David J. Anderson）。在上世紀40年代末期，豐田的經銷商們目睹了大型超市們如何根據賣場的貨物供銷資料來安排庫房中的庫存比例。這使得豐田公司開始着力打造這樣一種供應鍊體系，要根據汽車使用壽命周期中的零件損耗來評估存儲和供應安排。

看闆方法的主旨在抑制供應過剩。看闆方法通過借助看闆卡片和看闆這些可視化的實物，将産品周期中的物資流動關系展示出來。這樣的可視化管理最大程度地幫助人們看到整個流程的運轉，輔助管理層及時準确地制定供應計劃。

看闆方法還引入了“pull”這個概念，相比較傳統的“push”概念，讓勞工們在流水線上拿着固定薪水勞作或者強壓給員工一系列的待辦事項去完成，“pull”展現在能者多勞，多勞多得。

在軟體開發中。看闆方法意味着在許多代辦事項中，一個事項隻能同時有一個流程。換而言之，在一個團隊看闆上的“正在進行中”的這一列中，張貼的看闆卡片數目是有上限的。這樣做可以增加團隊的專注度，同時還減少了大家互相溝通的障礙。

看闆方法的另一個精髓就是嚴格的使用者需求導向，并且要不間斷地跟客戶溝通交流。直到真正意義上為客戶帶來效益，才算開發周期的完結。

準則

• 1、專注：減少同時參與處理多項事情。
• 2、減少浪費。
• 3、客戶需求第一位。（換而言之，要保證使用者的投資回報有收益）

實踐

• 1、可視化
• 2、在流程中把控工作
• 3、流程管理（主要展現在管理工作流程或者工作流程中的事項）
• 4、確定标準的清晰明了
• 5、使用使用者回報機制
• 6、實驗優化疊代

看闆方法和 Scrum 模型的主要差別是，

• 看闆方法是連續不間斷的而 Scrum 是不斷重複一個流程來達到疊代
• 看闆方法更适合那些需要在開發周期中處理很多不确定的工作的團隊（售後支援、緊急情況的處理，突發的重要請求等等）

如此一來，不像** Scrum 必須要等待一個疊代結束**，看闆方法支援事項一出現就開始進行工作，甚至連安排任務的優先級這一步都省卻了。

三、精益軟體開發

為了更好幫助你了解本段的主旨，最好的方法是先介紹下精益開發的創始人 Mary Poppendieck 的故事。在80年代，Marry 發現自己遇到了一個困境。

她那時在一家生産錄像帶的大型工廠任職 IT 部門主管，那時這家工廠的行程計劃表還是要用當時流行的 MRP 來制作。工廠的生存環境在一個很危險的境地裡，因為他們日本的競争對手生産的是更高品質的錄像帶，這種錄像帶播放更流暢而且售價更便宜。

這迫使 Marry 考慮使用他們競争對手的“準時制生産”政策。于是她拜讀了被翻譯成很蹩腳英文的一位豐田高管寫的一本書，就開始付諸行動。結果，幾乎是立竿見影就帶來了變化，工廠的周生産計劃從60%提高到95%。

這次的巨大成功讓她連同這家工廠獲益良多，也奠定了她日後跟自己丈夫 Tom Poppendieck 撰寫精益軟體開發流程的基礎。源于精益開發很多地方借鑒了看闆方法，你能從兩者間發現很多的相似處。

就像看闆方法一樣，精益講究減少浪費并追求客戶利益最大化。浪費可能會展現在建立錯誤的角色，項目出現空檔期，多任務同時進行，不斷切換工作事項，浪費時間做那些永遠不被采用或者永遠不會再次啟用的東西。

精益開發也從看闆那裡繼承了“pull”的概念，就是要相信你的同僚們在用盡他們最大的努力去完成工作（跟 Scrum 的互相尊重是一個道理）。

至于不同之處，差別于看闆方法，精益開發有一些要求工程師具體行動的行為準則（比如TDD 準則）。同時，精益開發沒有那麼嚴格把控傳遞時間，團隊可以在一切就緒的情況下随時傳遞産品。

還有一些其他跟精益開發緊密相關的概念，比如：最小可傳遞産品，就是盡可能快的傳遞你的産品，這個時間點通常是在還沒形成任何文檔的時候。還比如快速失敗概念和盡可能晚地達成捆綁協定（例如主營業務的決定之類的）

四、XP 極限程式設計

極限程式設計是由 Kent Beck 發起的一項實驗演化來的，那時的 Kent Beck 在 Chrysler 任職。這個實驗的初衷是要探索在極端情況下采用極緻的程式設計政策會發生什麼。例如，用結對程式設計來替換以往的代碼複查，當然技術環節的代碼評審還是不可以省略的。漸漸的，随着越來越多的公司開始采用極限程式設計，一些固化死闆的規矩也開始被忽略省去，例如每天的內建測試等。

如今，極限程式設計被那些采用其他靈活架構的團隊揉和在各自的架構中去最大限度地發掘團隊成員的開發潛力。

這裡還需要糾正一個錯誤的概念，極限程式設計不僅僅隻是結對程式設計。這隻是極限程式設計很多種實操過程中的一項而已，極限程式設計還同時為流程管理提供了一套推斷體系。

還需要說明的是，理論上所有的極限程式設計的實操應該同時組合使用，否則一切都是徒勞。也是因為如此，評論家們是這麼評論極限程式設計的，“好比兩條劇毒的蛇繞成一個圈在吞食對方的尾巴”或者“就是一座紙牌屋”，隻要其中任何一個細節出錯，都會影響到全局成敗。

極限程式設計在企業管理者中也受到了批判。比如，極限編譯要求時刻與客戶溝通，但實際中，客戶的經常到訪總會讓人感受到是一系列的壓力。同時，不注重形成需求文檔和開發文檔有時反倒是沒有效率。

價值點： 極限程式設計和 Scrum 有很多的關聯性，如下：

和看闆方法，精益開發一樣，極限程式設計也在追求減少浪費，專注于眼下的代碼開發而不是考慮明天的計劃或者下個月的安排等等。這種機制被稱作“YAGNI”方法（你壓根就不需要這些玩意）。當然，他們還有個相同之處就是都強調跟客戶走到一起共同完成。

實操方法

• 1、計劃遊戲
• 2、測試驅動開發（先寫單元測試）
• 3、結對程式設計
• 4、形成一個團隊（客戶以及軟體的真正使用人的意見回報）
• 5、持續內建
• 6、系統層面的重構改進
• 7、最小傳遞物
• 8、編碼标準
• 9、代碼統一保管
• 10、精簡設計
• 11、使用系統化名（用大家互相了解的規則給開發人員、客戶、以及其餘相關人員命名）
• 12、講究循序漸進（不提倡加班）

總結 本文裡，筆者試着闡述了四種靈活架構（ Scrum, Kanban, Lean, and XP）的不同之處。就像文章開篇說到的，實際工作中不可能隻用到一種特定的架構，團隊們都會摻雜着四種架構的實操手段應用到各自的工流程中。

轉自部落格：https://blog.csdn.net/belalds/article/details/93472674