文章較為系統(tǒng)地分享了關(guān)于敏捷開發(fā)的5種方法，希望能夠給你帶來一些幫助。

一、極限編程

極限編程（ExtremeProgramming，簡稱XP）是由KentBeck在1996年提出的。極限編程是一個輕量級的、靈巧的軟件開發(fā)方法；同時它也是一個非常嚴(yán)謹(jǐn)和周密的方法。

XP是一種近螺旋式的開發(fā)方法，它將復(fù)雜的開發(fā)過程分解為一個個相對比較簡單的小周期；通過積極的交流、反饋以及其它一系列的方法，開發(fā)人員和客戶可以非常清楚開發(fā)進(jìn)度、變化、待解決的問題和潛在的困難等，并根據(jù)實(shí)際情況及時地調(diào)整開發(fā)過程。

1.1、XP的核心價值

XP的核心價值觀是溝通（Communication）、簡單（Simplicity）、反饋（Feedback）、勇氣（Courage）、謙遜（Modesty）。 　XP用“溝通、簡單、反饋、勇氣和謙遜”來減輕開發(fā)壓力和包袱；無論是術(shù)語命名、專著敘述內(nèi)容和方式、過程要求，都可以從中感受到輕松愉快和主動奮發(fā)的態(tài)度和氣氛。這是一種幫助理解和更容易激發(fā)人的潛力的手段。XP用自己的實(shí)踐，在一定范圍內(nèi)成功地打破了軟件工程“必須重量”才能成功的傳統(tǒng)觀念。

XP精神可以啟發(fā)我們?nèi)绾螌W(xué)習(xí)和對待快速變化、多樣的開發(fā)技術(shù)。成功學(xué)習(xí)XP的關(guān)鍵，是用“溝通、簡單、反饋、勇氣和謙遜”的態(tài)度來對待XP；輕松愉快地來感受XP的實(shí)踐思想；自己認(rèn)真實(shí)踐后，通過對真實(shí)反饋的分析，來決定XP對自己的價值；有勇氣接受它，或改進(jìn)它。

1.2、為什么稱為“Extreme”（極限）

“Extreme”（極限）是指，對比傳統(tǒng)的項目開發(fā)方式，XP強(qiáng)調(diào)把它列出的每個方法和思想做到極限、做到最好；其它所不提倡的，XP則一概忽略（如開發(fā)前期的整體設(shè)計等）。一個嚴(yán)格實(shí)施XP的項目，其開發(fā)過程應(yīng)該是平穩(wěn)的、高效的和快速的，能夠做到一周40小時工作制而不拖延項目進(jìn)度。

1.3、XP核心實(shí)踐

基于敏捷的核心思想和價值目標(biāo)，XP要求項目團(tuán)隊遵循13個核心實(shí)踐

• 團(tuán)隊協(xié)作：通過客戶、開發(fā)團(tuán)隊、項目經(jīng)理三方共同參加的會議來確定開發(fā)計劃。
• 規(guī)劃策略： 計劃是持續(xù)的、循序漸進(jìn)的。每2周，開發(fā)人員就為下2周估算候選特性的成本，而客戶則根據(jù)成本和商務(wù)價值來選擇要實(shí)現(xiàn)的特性。
• 結(jié)對編程：系統(tǒng)的每一行代碼都是兩個人用一個鍵盤完成的。
• 測試驅(qū)動開發(fā)：先寫測試，后寫代碼。
• 重構(gòu)：不斷優(yōu)化系統(tǒng)設(shè)計，使之保持簡單。
• 簡單設(shè)計：為明確的功能進(jìn)行最優(yōu)的設(shè)計，不考慮未來可能需要的功能。
• 代碼集體所有權(quán)：開發(fā)隊伍中任何人可以修改任何其他人的代碼，代碼不屬于某個個人。
• 持續(xù)集成：至少每天將整個系統(tǒng)集成一次，保持一個能運(yùn)轉(zhuǎn)的系統(tǒng)。
• 客戶測試：客戶自己也是軟件開發(fā)隊伍的重要一份子。
• 小版本發(fā)布：盡快發(fā)布，盡早發(fā)布。
• 每周40小時工作制：保證休息，保持體力。
• 編碼標(biāo)準(zhǔn)：必須有統(tǒng)一的編碼規(guī)范，確保代碼的可讀性。
• 系統(tǒng)隱喻：將整個系統(tǒng)聯(lián)系在一起的全局視圖；它是系統(tǒng)的未來影像，是它使得所有單獨(dú)模塊的位置和外觀變得明顯直觀。如果模塊的外觀與整個隱喻不符，那么你就知道該模塊是錯誤的。

二、 水晶方法

水晶（Crystal）方法論由Alistair Cockburn在20世紀(jì)90年代末提出。他把開發(fā)看做是一系列的協(xié)作游戲，而寫文檔的目標(biāo)是幫助團(tuán)隊在下一個游戲中取得勝利。水晶方法的工作產(chǎn)品包括用例、風(fēng)險列表、迭代計劃、核心領(lǐng)域模型，以及記錄了一些選擇結(jié)果的設(shè)計注釋。水晶方法也為這些產(chǎn)品定義了相應(yīng)的角色。值得注意的是這些文檔沒有模板，描述也不太規(guī)范，但目標(biāo)清晰，能夠滿足下次游戲開始的條件。

對于水晶方法論，根據(jù)方法論的輕重可以分為透明水晶和橙色水晶等。透明水晶一般適用于輕量級的團(tuán)隊。不管是哪種水晶，都會對團(tuán)隊的角色、團(tuán)隊的工作項和產(chǎn)出、核心實(shí)踐、支持過程等進(jìn)行定義。

三、動態(tài)系統(tǒng)開發(fā)方法

動態(tài)系統(tǒng)開發(fā)方法（DSDM）倡導(dǎo)以業(yè)務(wù)為核心，快速而有效地進(jìn)行系統(tǒng)開發(fā)?？梢园袲SDM看成一種控制框架，其重點(diǎn)在于快速交付并補(bǔ)充如何應(yīng)用這些控制的指導(dǎo)原則。

DSDM是一整套的方法論，不僅僅包括軟件開發(fā)內(nèi)容和實(shí)踐，也包括了組織結(jié)構(gòu)、項目管理、估算、工具環(huán)境、測試、配置管理、風(fēng)險管理、重用等各個方面的內(nèi)容。

3.1、DSDM的基本觀點(diǎn)

DSDM認(rèn)為任何事情都不可能一次性圓滿完成，應(yīng)該用20%的時間完成80%的有用功能，以適合商業(yè)目的為準(zhǔn)。實(shí)施的思路是，在時間進(jìn)度和可用資源預(yù)先固定的情況下，力爭最大化地滿足業(yè)務(wù)需求（傳統(tǒng)方法一般是需求固定，時間和資源可變），交付所需要的系統(tǒng)。對于交付的系統(tǒng)，必須達(dá)到足夠的穩(wěn)定程度以在實(shí)際環(huán)境中運(yùn)行；對于業(yè)務(wù)方面的某些緊急需求，也必須能夠在短時間內(nèi)得到滿足，并在后續(xù)迭代階段中對功能進(jìn)行完善。

3.2、DSDM的基本原則

• 活動用戶必須參與。
• 必須授權(quán)DSDM團(tuán)隊進(jìn)行決策。
• 注重頻繁交付產(chǎn)品。
• 判斷產(chǎn)品是否可接受的一個基本標(biāo)準(zhǔn)是符合業(yè)務(wù)目的。
• 對準(zhǔn)確的業(yè)務(wù)解決方案需要采用循環(huán)和增量開發(fā)。
• 開發(fā)期間的所有更改都是可逆的。
• 基本要求是高層次的并區(qū)分優(yōu)先級（以在低優(yōu)先級的項目上獲得一定的靈活性）。
• 在整個生命周期集成測試。
• 在所有參與者之間采用協(xié)作和合作方法。

四、精益開發(fā)

精益（Lean）管理的思想起源于豐田公司，旨在創(chuàng)造價值的目標(biāo)下，通過改良流程不斷地消除浪費(fèi)。這種方法現(xiàn)已被廣泛用于生產(chǎn)制造管理，對于IT系統(tǒng)建設(shè)，精益開發(fā)的常用工具模型是價值流模型。

4.1、精益開發(fā)的基本原則

• 杜絕浪費(fèi)：將所有的時間花在能夠增加客戶價值的事情上。
• 推遲決策：根據(jù)實(shí)際情況保持可選方案的開放性，但時間不能過長。
• 加強(qiáng)學(xué)習(xí)：使用科學(xué)的學(xué)習(xí)方法。
• 快速交付：當(dāng)客戶索取價值時應(yīng)立即交付價值。
• 打造精品：使用恰當(dāng)?shù)姆椒ù_保質(zhì)量。
• 授權(quán)團(tuán)隊：讓創(chuàng)造增值的員工充分發(fā)揮自己的潛力。
• 優(yōu)化整體：防止以損害整體為代價而優(yōu)化部分的傾向。

五、Scrum

Scrum 是一個用于開發(fā)和維護(hù)復(fù)雜產(chǎn)品的框架 ，是一個增量的、迭代的開發(fā)過程。在這個框架中，整個開發(fā)過程由若干個短的迭代周期組成，一個短的迭代周期稱為一個Sprint，每個Sprint的建議長度是2到4周。

在Scrum中，使用產(chǎn)品Backlog來管理產(chǎn)品的需求，產(chǎn)品backlog是一個按照商業(yè)價值排序的需求列表，列表條目的體現(xiàn)形式通常為用戶故事。Scrum團(tuán)隊總是先開發(fā)對客戶具有較高價值的需求。在Sprint中，Scrum團(tuán)隊從產(chǎn)品Backlog中挑選最高優(yōu)先級的需求進(jìn)行開發(fā)。

挑選的需求在Sprint計劃會議上經(jīng)過討論、分析和估算得到相應(yīng)的任務(wù)列表，我們稱它為Sprint backlog。在每個迭代結(jié)束時，Scrum團(tuán)隊將遞交潛在可交付的產(chǎn)品增量。 Scrum起源于軟件開發(fā)項目，但它適用于任何復(fù)雜的或是創(chuàng)新性的項目。

5.1、Scrum 過程框架

Scrum以經(jīng)驗性過程控制理論（經(jīng)驗主義）做為理論基礎(chǔ)的過程。經(jīng)驗主義主張知識源于經(jīng)驗, 以及基于已知的東西做決定。Scrum 采用迭代、增量的方法來優(yōu)化可預(yù)見性并控制風(fēng)險。Scrum過程框架的基石包括如下三個方面：

第一：透明性（Transparency）。透明度是指，在軟件開發(fā)過程的各個環(huán)節(jié)保持高度的可見性，影響交付成果的各個方面對于參與交付的所有人、管理生產(chǎn)結(jié)果的人保持透明。管理生產(chǎn)成果的人不僅要能夠看到過程的這些方面，而且必須理解他們看到的內(nèi)容。也就是說，當(dāng)某個人在檢驗一個過程，并確信某一個任務(wù)已經(jīng)完成時，這個完成必須等同于他們對完成的定義。

第二：檢驗（Inspection）。開發(fā)過程中的各方面必須做到足夠頻繁地檢驗，確保能夠及時發(fā)現(xiàn)過程中的重大偏差。在確定檢驗頻率時，需要考慮到檢驗會引起所有過程發(fā)生變化。當(dāng)規(guī)定的檢驗頻率超出了過程檢驗所能容許的程度，那么就會出現(xiàn)問題。幸運(yùn)的是，軟件開發(fā)并不會出現(xiàn)這種情況。另一個因素就是檢驗工作成果人員的技能水平和積極性。

第三：適應(yīng)（Adaptation）。如果檢驗人員檢驗的時候發(fā)現(xiàn)過程中的一個或多個方面不滿足驗收標(biāo)準(zhǔn)，并且最終產(chǎn)品是不合格的，那么便需要對過程或是材料進(jìn)行調(diào)整。調(diào)整工作必須盡快實(shí)施，以減少進(jìn)一步的偏差。

Scrum中通過三個活動進(jìn)行檢驗和適應(yīng)：每日例會檢驗Sprint目標(biāo)的進(jìn)展，做出調(diào)整，從而優(yōu)化次日的工作價值；Sprint評審和計劃會議檢驗發(fā)布目標(biāo)的進(jìn)展，做出調(diào)整，從而優(yōu)化下一個Sprint的工作價值；Sprint回顧會議是用來回顧已經(jīng)完成的Sprint，并且確定做出什么樣的改善可以使接下來的Sprint更加高效、更加令人滿意，并且工作更快樂。

5.2、Scrum的四大支柱

第一、迭代開發(fā)。在Scrum的開發(fā)模式下，我們將開發(fā)周期分成多個1-4周的迭代，每個迭代都交付一些增量的可工作的功能。迭代的長度是固定的，如果我們選擇了1周的迭代，那么保持它的長度不要發(fā)生變化，在整個產(chǎn)品開發(fā)周期內(nèi)每個迭代都是1周的長度。這里需要強(qiáng)調(diào)的是在每個迭代必須產(chǎn)出可工作的增量功能，而不是第一個迭代做需求、第二個迭代做設(shè)計、第三個迭代做代碼。

第二、增量交付。增量是一個 Sprint 及以前所有 Sprint 中完成的所有產(chǎn)品代辦事項列表條目的總和。 在 Sprint 的結(jié)尾,新的增量必須“完成”,這意味著它必須可用并且達(dá)到了 Scrum 團(tuán)隊 “完成”的定義的標(biāo)準(zhǔn)。無論產(chǎn)品負(fù)責(zé)人是否決定真正發(fā)布它,增量必須可用。增量是從用戶的角度來描述的，它意味著從用戶的角度可工作。

第三、自組織團(tuán)隊。Scrum團(tuán)隊是一個自組織的團(tuán)隊，傳統(tǒng)的命令與控制式的團(tuán)隊只有執(zhí)行任務(wù)的權(quán)利，而自組織團(tuán)隊有權(quán)進(jìn)行設(shè)計、計劃和執(zhí)行任務(wù)，自組織團(tuán)隊還需要自己監(jiān)督和管理他們的工程過程和進(jìn)度，自組織團(tuán)隊自己決定團(tuán)隊內(nèi)如何開展工作，決定誰來做什么，即分工協(xié)作的方式。

第四、高優(yōu)先級的需求驅(qū)動。在Scrum中，我們使用Product Backlog來管理需求，Product Backlog是一個需求的清單，Product Backlog中的需求是漸進(jìn)明細(xì)的，Backlog當(dāng)中的條目必須按照商業(yè)價值的高低排序。Scrum團(tuán)隊在開發(fā)需求的時候，從Backlog最上層的高優(yōu)先級的需求開始開發(fā)。在Scrum中，只要有足夠1-2個Sprint開發(fā)的細(xì)化了的高優(yōu)先級的需求，我們就可以啟動Sprint了，而不必等到所有的需求都細(xì)化之后。我們可以在開發(fā)期間通過Backlog的梳理來逐步的細(xì)化需求。

5.3、Scrum團(tuán)隊介紹

在Scrum的工作方式下，總共只有三個角色， 這三個角色分別是產(chǎn)品負(fù)責(zé)人（PO）,Scrum Master和開發(fā)團(tuán)隊。

我們通?？梢砸詣濤堉鄣膱F(tuán)隊角色來類比Scrum的角色，劃龍舟通常有舵手、鼓手、劃槳團(tuán)隊三個角色。Scrum中的PO就是舵手的角色，他對產(chǎn)品的方向負(fù)責(zé)，對產(chǎn)品的Why和What負(fù)責(zé)，對產(chǎn)品的愿景，產(chǎn)品包括哪些主要的特性負(fù)責(zé)。Scrum中的Scrum Master鼓手的角色，他幫助團(tuán)隊保持高昂的士氣，并進(jìn)行良好的協(xié)作，他是一個Scrum的專家，團(tuán)隊的教練，團(tuán)隊的服務(wù)式領(lǐng)導(dǎo)。Scrum中的團(tuán)隊，對應(yīng)到龍舟賽的劃槳團(tuán)隊，團(tuán)隊必須協(xié)調(diào)一致，作為一個整體前進(jìn)，在這樣的環(huán)境下單打獨(dú)斗，各自為政沒有任何勝算。

Scrum的開發(fā)團(tuán)隊對實(shí)現(xiàn)Sprint目標(biāo)需要做的所有事情負(fù)責(zé)，包括技術(shù)方案和決策，團(tuán)隊分工（誰做什么），執(zhí)行Sprint開發(fā)任務(wù)等，而且作為自組織的團(tuán)隊，他們也對他們的工作進(jìn)度的跟蹤和管理負(fù)責(zé)。Scrum開發(fā)團(tuán)隊的主要職責(zé)包括如下五個方面：

• 執(zhí)行Sprint
• 每日檢視和調(diào)整，每個開發(fā)團(tuán)隊成員都應(yīng)該參與每日站會，一起檢驗Sprint目標(biāo)的進(jìn)展情況，跟進(jìn)當(dāng)天的工作情況調(diào)整計劃。
• 梳理產(chǎn)品列表，每個Sprint都需要花一些時間來準(zhǔn)備下一個Sprint，主要用來梳理產(chǎn)品列表，包括PBI的創(chuàng)建和細(xì)化、估算和排列優(yōu)先級順序。
• sprint規(guī)劃，在Sprint計劃會議（Sprint Planning Meeting）上，在ScrumMaster的引導(dǎo)下，開發(fā)團(tuán)隊和PO合作，為下一個Sprint建立目標(biāo)。
• 檢視和調(diào)整產(chǎn)品與過程，每個Sprint結(jié)束后，開發(fā)團(tuán)隊都要參加兩個檢視和調(diào)整的活動，即Sprint評審會議（Sprint Review Meeting）和 Sprint回顧會議（Sprint Retrospective Meeting）。

5.4、什么是用戶故事

用戶故事是從用戶的角度來描述用戶渴望得到的功能。一個好的用戶故事包括三個要素：

1. 角色：誰要使用這個功能。
2. 活動：需要完成什么樣的功能。
3. 商業(yè)價值：為什么需要這個功能，這個功能帶來什么樣的價值。

用戶故事通常按照如下的格式來表達(dá)：作為一個<角色>, 我想要<活動>, 以便于<商業(yè)價值>

本文由 @PMO雜談 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Pixabay，基于CC0協(xié)議