敏捷框架大PK：Scrum 方法 vs 看板方法 vs 精益開發 vs 極限編程

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

因此，人們從實踐中總結真知，就衍生出了實現敏捷的各種各樣的方法。其中，最廣為人知的當屬 Scrum 方法、看板方法、精益開發以及極限編程。

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

敏捷框架對比： Scrum 方法 vs 看板方法 vs 精益開發 vs 極限編程，4種敏捷框架有啥核心區別？

敏捷開發以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發。在敏捷開發中，軟件項目在構建初期被切分成多個子項目，各個子項目的成果都經過測試，具備可視、可集成和可運行使用的特征。換言之，就是把一個大項目分為多個相互聯系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態。

什么是敏捷開發？

敏捷開發(Agile Development)是一種以人為核心、迭代、循序漸進的開發方法。

怎么理解呢？首先，我們要理解它不是一門技術，它是一種開發方法，也就是一種軟件開發的流程，它會指導我們用規定的環節去一步一步完成項目的開發；而這種開發方式的主要驅動核心是人；它采用的是迭代式開發；

為什么說是以人為核心？

我們大部分人都學過瀑布開發模型，它是以文檔為驅動的，為什么呢？因為在瀑布的整個開發過程中，要寫大量的文檔，把需求文檔寫出來后，開發人員都是根據文檔進行開發的，一切以文檔為依據；而敏捷開發它只寫有必要的文檔，或盡量少寫文檔，敏捷開發注重的是人與人之間，面對面的交流，所以它強調以人為核心。

什么是迭代？

迭代是指把一個復雜且開發周期很長的開發任務，分解為很多小周期可完成的任務，這樣的一個周期就是一次迭代的過程；同時每一次迭代都可以生產或開發出一個可以交付的軟件產品。

有哪些敏捷開發方法？

敏捷不是指某一種具體的方法論、過程或框架，而是一組價值觀和原則。符合敏捷價值觀和原則的開發方法包括：極限編程（XP），Scrum，精益軟件開發（Lean Software Development），動態系統開發方法（DSDM），特征驅動開發（Feature Driver Development），水晶開發（Crystal Clear）等等。

所有這些方法都具有以下共同特征：

迭代式開發。即整個開發過程被分為幾個迭代周期，每個迭代周期是一個定長或不定長的時間塊每個迭代周期持續的時間一般較短，通常為一到六周。

增量交付。產品是在每個迭代周期結束時被逐步交付使用，而不是在整個開發過程結束的時候一次***付使用。每次交付的都是可以被部署到用戶應用環境中被用戶使用的、能給用戶帶來即時效益和價值的產品。

開發團隊和用戶反饋推動產品開發。敏捷開發方法主張用戶能夠全程參與到整個開發過程中。這使需求變化和用戶反饋能被動態管理并及時集成到產品中。同時，團隊對于用戶的需求也能及時提供反饋意見。

持續集成。新的功能或需求變化總是盡可能頻繁地被整合到產品中。一些項目是在每個迭代周期結束的時候集成， 有些項目則每天都在這么做。

開發團隊自我管理。擁有一個積極的、自我管理的、具備自由交流風格的開發團隊，是每個敏捷項目必不可少的條件。人是敏捷開發的核心。敏捷開發總是以人為中心建立開發的過程和機制，而非把過程和機制強加給人。

一、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（文檔表格）。像燃盡圖，流程圖之類的，用于把控團隊流程的文檔。

Scrum流程圖

角色有哪些

1、Development Team.（開發成員組）這個小組中包含了測試，前端開發，需求分析師，等等所有迭代開發程序需要的人員。Scrum 的成員基本上會控制在3-9人。假如說人員擴充超過了9人限制，就需要將團隊一分為二。

2、Scrum Master（敏捷專家），SM 們需要主持召開每日的站會，以及開發前的計劃會議、開發中的梳理流程會議、開發后的回顧總結會議，還有個重任是要幫助團隊成員們解決所有關系到溝通的事宜。SM 不是開發小組的成員，所以多個敏捷小組可以同時共享一名Scrum Master。

3、Product Owner（產品經理），站在客戶的立場，用客戶的眼光（這樣的視角可以更貼近現實情況地編寫用戶故事）來幫助敏捷團隊開發，PO 的工作還包括評定用戶故事的優先次序，并在每次沖擊計劃完成后評估交付的成果物是否符合要求。

價值點：

1、目標性明確（完成每一次的沖刺計劃）

2、有勇氣（敢于做大家一致認同正確的決定）

3、有專注度（每次的迭代只專注一個事項）

4、開放性（積極面對各種各樣的挑戰）

5、相互信賴（彼此相信都在用盡自己最大的努力做事情）

什么是Sprint？

Sprint是短距離賽跑的意思，這里面指的是一次迭代，而一次迭代的周期是1個月時間（即4個星期），也就是我們要把一次迭代的開發內容以最快的速度完成它，這個過程我們稱它為Sprint。

如何進行Scrum開發？

1、我們首先需要確定一個Product Backlog（按優先順序排列的一個產品需求列表），這個是由Product Owner 負責的；

2、Scrum Team根據Product Backlog列表，做工作量的預估和安排；

3、有了Product Backlog列表，我們需要通過 Sprint Planning Meeting（Sprint計劃會議） 來從中挑選出一個Story作為本次迭代完成的目標，這個目標的時間周期是1~4個星期，然后把這個Story進行細化，形成一個Sprint Backlog；

4、Sprint Backlog是由Scrum Team去完成的，每個成員根據Sprint Backlog再細化成更小的任務（細到每個任務的工作量在2天內能完成）；

5、在Scrum Team完成計劃會議上選出的Sprint Backlog過程中，需要進行 Daily Scrum Meeting（每日站立會議），每次會議控制在15分鐘左右，每個人都必須發言，并且要向所有成員當面匯報你昨天完成了什么，并且向所有成員承諾你今天要完成什么，同時遇到不能解決的問題也可以提出，每個人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃盡圖）；

6、做到每日集成，也就是每天都要有一個可以成功編譯、并且可以演示的版本；很多人可能還沒有用過自動化的每日集成，其實TFS就有這個功能，它可以支持每次有成員進行簽入操作的時候，在服務器上自動獲取最新版本，然后在服務器中編譯，如果通過則馬上再執行單元測試代碼，如果也全部通過，則將該版本發布，這時一次正式的簽入操作才保存到TFS中，中間有任何失敗，都會用郵件通知項目管理人員；

7、當一個Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，這時，我們要進行 Srpint Review Meeting（演示會議），也稱為評審會議，產品負責人和客戶都要參加（最好本公司老板也參加），每一個Scrum Team的成員都要向他們演示自己完成的軟件產品（這個會議非常重要，一定不能取消）；

8、最后就是 Sprint Retrospective Meeting（回顧會議），也稱為總結會議，以輪流發言方式進行，每個人都要發言，總結并討論改進的地方，放入下一輪Sprint的產品需求中；

二、看板方法

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

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

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

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

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

準則

1、專注：減少同時參與處理多項事情。

2、減少浪費。

3、客戶需求第一位。（換而言之，要保證用戶的投資回報有收益）

實踐

1、可視化

2、在流程中把控工作

3、流程管理（主要體現在管理工作流程或者工作流程中的事項）

4、確保標準的清晰明了

5、使用用戶反饋機制

6、實驗優化迭代

看板方法和 Scrum 模型的主要區別是，看板方法是連續不間斷的而 Scrum 是不斷重復一個流程來達到迭代。看板方法更適合那些需要在開發周期中處理很多不確定的工作的團隊（售后支持、緊急情況的處理，突發的重要請求等等）。

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

三、精益軟件開發http://www.scrumcn.com/agile/scrum-knowledge-library/agile-development.html#tab-id-8

為了更好幫助你了解本段的主旨，最好的方法是先介紹下精益開發的創始人 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、講究循序漸進（不提倡加班）

管理常用工具

1、ZenTaoPHP輕量級的PHP項目管理開發框架，一開源的項目管理軟件

官網：http://www.zentao.net

下載：http://www.zentao.net/download

2.Jira + Confluence ? ? ?基于Java 收費模式 包含Bug追蹤和Wiki

官網:http://www.atlassian.com/software/jira/

在線演示站點：http://jira.fangwai.net/secure/Dashboard.jspa

3.XPlanner 采用極限編程開發(XP)流程

官網：http://www.xplanner.org

4、leangoo領歌，一款基于看板的項目協作軟件

https://www.leangoo.com/

總結

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

數據來源：

敏捷官網：https://www.agilealliance.org/

scrum中文網：http://www.scrumcn.com/agile/scrum-knowledge-library/agile-development.html

軟件開發 流水線 CloudPipeline 敏捷開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。