張洪強
一、極限編程
極限編程（ExtremeProgramming，簡稱XP）是由KentBeck在1996年提出的。極限編程是一個輕量級的、靈巧的軟件開發方法；同時它也是一個非常嚴謹和周密的方法。XP是一種近螺旋式的開發方法，它將複雜的開發過程分解為一個個相對比較簡單的小週期；通過積極的交流、反饋以及其它一系列的方法，開發人員和客戶可以非常清楚開發進度、變化、待解決的問題和潛在的困難等，並根據實際情況及時地調整開發過程。
1.1、XP的核心價值
XP的核心價值觀是溝通（Communication）、簡單（Simplicity）、反饋（Feedback）、勇氣（Courage）、謙遜（Modesty）。 XP用“溝通、簡單、反饋、勇氣和謙遜”來減輕開發壓力和包袱；無論是術語命名、專著敘述內容和方式、過程要求，都可以從中感受到輕鬆愉快和主動奮發的態度和氣氛。這是一種幫助理解和更容易激發人的潛力的手段。XP用自己的實踐，在一定範圍內成功地打破了軟件工程“必須重量”才能成功的傳統觀念。
XP精神可以啟發我們如何學習和對待快速變化、多樣的開發技術。成功學習XP的關鍵，是用“溝通、簡單、反饋、勇氣和謙遜”的態度來對待XP；輕鬆愉快地來感受XP的實踐思想；自己認真實踐後，通過對真實反饋的分析，來決定XP對自己的價值；有勇氣接受它，或改進它。
1.2、為什麼稱為“Extreme”（極限）
“Extreme”（極限）是指，對比傳統的項目開發方式，XP強調把它列出的每個方法和思想做到極限、做到最好；其它所不提倡的，XP則一概忽略（如開發前期的整體設計等）。一個嚴格實施XP的項目，其開發過程應該是平穩的、高效的和快速的，能夠做到一週40小時工作制而不拖延項目進度。
1.3、XP核心實踐
基於敏捷的核心思想和價值目標，XP要求項目團隊遵循13個核心實踐
l 團隊協作：通過客戶、開發團隊、項目經理三方共同參加的會議來確定開發計劃。
l 規劃策略： 計劃是持續的、循序漸進的。每2周，開發人員就為下2周估算候選特性的成本，而客戶則根據成本和商務價值來選擇要實現的特性。
l 結對編程：系統的每一行代碼都是兩個人用一個鍵盤完成的。
l 測試驅動開發：先寫測試，後寫代碼。
l 重構：不斷優化系統設計，使之保持簡單。
l 簡單設計：為明確的功能進行最優的設計，不考慮未來可能需要的功能。
l 代碼集體所有權：開發隊伍中任何人可以修改任何其他人的代碼，代碼不屬於某個個人。
l 持續集成：至少每天將整個系統集成一次，保持一個能運轉的系統。
l 客戶測試：客戶自己也是軟件開發隊伍的重要一份子。
l 小版本發佈：儘快發佈，儘早發佈。
l 每週40小時工作制：保證休息，保持體力。
l 編碼標準：必須有統一的編碼規範，確保代碼的可讀性。
l 系統隱喻：將整個系統聯繫在一起的全局視圖；它是系統的未來影像，是它使得所有單獨模塊的位置和外觀變得明顯直觀。如果模塊的外觀與整個隱喻不符，那麼你就知道該模塊是錯誤的。
二、 水晶方法
水晶（Crystal）方法論由Alistair Cockburn在20世紀90年代末提出。他把開發看做是一系列的協作遊戲，而寫文檔的目標是幫助團隊在下一個遊戲中取得勝利。水晶方法的工作產品包括用例、風險列表、迭代計劃、核心領域模型，以及記錄了一些選擇結果的設計註釋。水晶方法也為這些產品定義了相應的角色。值得注意的是這些文檔沒有模板，描述也不太規範，但目標清晰，能夠滿足下次遊戲開始的條件。
對於水晶方法論，根據方法論的輕重可以分為透明水晶和橙色水晶等。透明水晶一般適用於輕量級的團隊。不管是哪種水晶，都會對團隊的角色、團隊的工作項和產出、核心實踐、支持過程等進行定義。
三、動態系統開發方法
動態系統開發方法（DSDM）倡導以業務為核心，快速而有效地進行系統開發。可以把DSDM看成一種控制框架，其重點在於快速交付並補充如何應用這些控制的指導原則。
DSDM是一整套的方法論，不僅僅包括軟件開發內容和實踐，也包括了組織結構、項目管理、估算、工具環境、測試、配置管理、風險管理、重用等各個方面的內容。
3.1、DSDM的基本觀點
DSDM認為任何事情都不可能一次性圓滿完成，應該用20%的時間完成80%的有用功能，以適合商業目的為準。實施的思路是，在時間進度和可用資源預先固定的情況下，力爭最大化地滿足業務需求（傳統方法一般是需求固定，時間和資源可變），交付所需要的系統。對於交付的系統，必須達到足夠的穩定程度以在實際環境中運行；對於業務方面的某些緊急需求，也必須能夠在短時間內得到滿足，並在後續迭代階段中對功能進行完善。
3.2、DSDM的基本原則
- 活動用戶必須參與。
- 必須授權DSDM團隊進行決策。
- 注重頻繁交付產品。
- 判斷產品是否可接受的一個基本標準是符合業務目的。
- 對準確的業務解決方案需要採用循環和增量開發。
- 開發期間的所有更改都是可逆的。
- 基本要求是高層次的並區分優先級（以在低優先級的項目上獲得一定的靈活性）。
- 在整個生命週期集成測試。
- 在所有參與者之間採用協作和合作方法。
四、精益開發
精益（Lean）管理的思想起源於豐田公司，旨在創造價值的目標下，通過改良流程不斷地消除浪費。這種方法現已被廣泛用於生產製造管理，對於IT系統建設，精益開發的常用工具模型是價值流模型。
4.1、精益開發的基本原則
- 杜絕浪費：將所有的時間花在能夠增加客戶價值的事情上。
- 推遲決策：根據實際情況保持可選方案的開放性，但時間不能過長。
- 加強學習：使用科學的學習方法。
- 快速交付：當客戶索取價值時應立即交付價值。
- 打造精品：使用恰當的方法確保質量。
- 授權團隊：讓創造增值的員工充分發揮自己的潛力。
- 優化整體：防止以損害整體為代價而優化部分的傾向。
五、Scrum
Scrum 是一個用於開發和維護複雜產品的框架 ，是一個增量的、迭代的開發過程。在這個框架中，整個開發過程由若干個短的迭代週期組成，一個短的迭代週期稱為一個Sprint，每個Sprint的建議長度是2到4周。在Scrum中，使用產品Backlog來管理產品的需求，產品backlog是一個按照商業價值排序的需求列表，列表條目的體現形式通常為用戶故事。Scrum團隊總是先開發對客戶具有較高價值的需求。
在Sprint中，Scrum團隊從產品Backlog中挑選最高優先級的需求進行開發。挑選的需求在Sprint計劃會議上經過討論、分析和估算得到相應的任務列表，我們稱它為Sprint backlog。在每個迭代結束時，Scrum團隊將遞交潛在可交付的產品增量。 Scrum起源於軟件開發項目，但它適用於任何複雜的或是創新性的項目。
5.1、Scrum 過程框架
Scrum以經驗性過程控制理論（經驗主義）做為理論基礎的過程。經驗主義主張知識源於經驗, 以及基於已知的東西做決定。Scrum 採用迭代、增量的方法來優化可預見性並控制風險。Scrum過程框架的基石包括如下三個方面：
第一：透明性（Transparency）。透明度是指，在軟件開發過程的各個環節保持高度的可見性，影響交付成果的各個方面對於參與交付的所有人、管理生產結果的人保持透明。管理生產成果的人不僅要能夠看到過程的這些方面，而且必須理解他們看到的內容。也就是說，當某個人在檢驗一個過程，並確信某一個任務已經完成時，這個完成必須等同於他們對完成的定義。
第二：檢驗（Inspection）。開發過程中的各方面必須做到足夠頻繁地檢驗，確保能夠及時發現過程中的重大偏差。在確定檢驗頻率時，需要考慮到檢驗會引起所有過程發生變化。當規定的檢驗頻率超出了過程檢驗所能容許的程度，那麼就會出現問題。幸運的是，軟件開發並不會出現這種情況。另一個因素就是檢驗工作成果人員的技能水平和積極性。
第三：適應（Adaptation）。如果檢驗人員檢驗的時候發現過程中的一個或多個方面不滿足驗收標準，並且最終產品是不合格的，那麼便需要對過程或是材料進行調整。調整工作必須儘快實施，以減少進一步的偏差。
Scrum中通過三個活動進行檢驗和適應：每日例會檢驗Sprint目標的進展，做出調整，從而優化次日的工作價值；Sprint評審和計劃會議檢驗發佈目標的進展，做出調整，從而優化下一個Sprint的工作價值；Sprint回顧會議是用來回顧已經完成的Sprint，並且確定做出什麼樣的改善可以使接下來的Sprint更加高效、更加令人滿意，並且工作更快樂。
5.2、Scrum的四大支柱
第一、迭代開發。在Scrum的開發模式下，我們將開發週期分成多個1-4周的迭代，每個迭代都交付一些增量的可工作的功能。迭代的長度是固定的，如果我們選擇了1周的迭代，那麼保持它的長度不要發生變化，在整個產品開發週期內每個迭代都是1周的長度。這裡需要強調的是在每個迭代必須產出可工作的增量功能，而不是第一個迭代做需求、第二個迭代做設計、第三個迭代做代碼。
第二、增量交付。增量是一個 Sprint 及以前所有 Sprint 中完成的所有產品代辦事項列表條目的總和。在 Sprint 的結尾,新的增量必須“完成”,這意味著它必須可用並且達到了 Scrum 團隊 “完成”的定義的標準。無論產品負責人是否決定真正發佈它,增量必須可用。增量是從用戶的角度來描述的，它意味著從用戶的角度可工作。
第三、自組織團隊。Scrum團隊是一個自組織的團隊，傳統的命令與控制式的團隊只有執行任務的權利，而自組織團隊有權進行設計、計劃和執行任務，自組織團隊還需要自己監督和管理他們的工程過程和進度，自組織團隊自己決定團隊內如何開展工作，決定誰來做什麼，即分工協作的方式。
第四、高優先級的需求驅動。在Scrum中，我們使用Product Backlog來管理需求，Product Backlog是一個需求的清單，Product Backlog中的需求是漸進明細的，Backlog當中的條目必須按照商業價值的高低排序。Scrum團隊在開發需求的時候，從Backlog最上層的高優先級的需求開始開發。在Scrum中，只要有足夠1-2個Sprint開發的細化了的高優先級的需求，我們就可以啟動Sprint了，而不必等到所有的需求都細化之後。我們可以在開發期間通過Backlog的梳理來逐步的細化需求。
5.3、Scrum團隊介紹
在Scrum的工作方式下，總共只有三個角色，
這三個角色分別是產品負責人（PO）,Scrum Master和開發團隊。
我們通常可以以划龍舟的團隊角色來類比Scrum的角色，划龍舟通常有舵手、鼓手、划槳團隊三個角色。Scrum中的PO就是舵手的角色，他對產品的方向負責，對產品的Why和What負責，對產品的願景，產品包括哪些主要的特性負責。Scrum中的Scrum Master鼓手的角色，他幫助團隊保持高昂的士氣，並進行良好的協作，他是一個Scrum的專家，團隊的教練，團隊的服務式領導。Scrum中的團隊，對應到龍舟賽的划槳團隊，團隊必須協調一致，作為一個整體前進，在這樣的環境下單打獨鬥，各自為政沒有任何勝算。
Scrum的開發團隊對實現Sprint目標需要做的所有事情負責，包括技術方案和決策，團隊分工（誰做什麼），執行Sprint開發任務等，而且作為自組織的團隊，他們也對他們的工作進度的跟蹤和管理負責。Scrum開發團隊的主要職責包括如下五個方面：
- 執行Sprint
- 每日檢視和調整，每個開發團隊成員都應該參與每日站會，一起檢驗Sprint目標的進展情況，跟進當天的工作情況調整計劃。
- 梳理產品列表，每個Sprint都需要花一些時間來準備下一個Sprint，主要用來梳理產品列表，包括PBI的創建和細化、估算和排列優先級順序。
- sprint規劃，在Sprint計劃會議（Sprint Planning Meeting）上，在ScrumMaster的引導下，開發團隊和PO合作，為下一個Sprint建立目標。
- 檢視和調整產品與過程，每個Sprint結束後，開發團隊都要參加兩個檢視和調整的活動，即Sprint評審會議（Sprint Review Meeting）和 Sprint回顧會議（Sprint Retrospective Meeting）。
5.4、什麼是用戶故事
用戶故事是從用戶的角度來描述用戶渴望得到的功能。一個好的用戶故事包括三個要素：
1. 角色：誰要使用這個功能。
2. 活動：需要完成什麼樣的功能。
3. 商業價值：為什麼需要這個功能，這個功能帶來什麼樣的價值。
用戶故事通常按照如下的格式來表達：作為一個, 我想要, 以便於
