瀑布式開發、迭代開發、敏捷開發、XP與SCRUM的區別

瀑布式開發、迭代開發，區別【都屬於，生命週期模型】

---

         二者都是一種開發模式，就像設計模式同樣，考慮的角度不同，我的感受談不到取代一說。

         傳統的瀑布式開發，也就是從需求到設計，從設計到編碼，從編碼到測試，從測試到提交大概這樣的流程，要求每個開發階段都要作到最好。特別是前期階段，設計的越完美，提交後的成本損失就越少。我如今從事的外包項目就是這樣的流程。

         迭代式開發，不要求每個階段的任務作的都是最完美的，而是明明知道還有不少不足的地方，卻恰恰不去完善它，而是把主要功能先搭建起來爲目的，以最短的時間，最少的損失先完成一個「不完美的成果物」直至提交。而後再經過客戶或用戶的反饋信息，在這個「不完美的成果物」上逐步進行完善。

        這兩種開發模式都各自具備本身的特色，迭代式開發適合在一些需求信息不明確的項目中，這樣在開發過程當中遇到需求的變化時，所帶來的影響要比瀑布式開發小。而如今的不少項目中，需求在項目進行中變化的事兒常常見，因此顯得迭代式開發的優點更明顯一些。

        可是，從本質上來講，兩者都不過是一種開發的模式，即便是迭代式開發，在每個迭代的環節中，不也是此從需求到設計，從設計到編碼，從編碼到測試嗎？這不也是瀑布式模型的體現嗎？只不過這個瀑布式中的每個階段不須要作到最優化，都留一些任務到下一層迭代中去作而已。

        因此，我以爲面對不一樣的問題採用不一樣的模式，模式是爲了方便咱們開發而服務的，不是要求咱們必須按照某一種模式從頭走到尾。

        就象迭代式開發，咱們其實也常常用到這種模式。好比說開發項目中的某一個模塊。咱們先把可以實現主要功能的代碼寫出來。好比一個查詢模塊，先從模塊的構思到設計再到編碼，先查詢功能的代碼，測試一遍查詢成功。這算是完成了第一層迭代。而後咱們要再考慮一層迭代中的一些還未完成的細節問題，好比查詢的check，查詢結果的顯示以及查詢算法的優化等等，這就是第二層迭代。

 

瀑布式開發，敏捷開發，區別【一種生命週期模型，項目管理方法集合】

---

瀑布模型的特色（傳統的開發方式）

一、強調文檔

前一個階段的輸出就是下一個階段的輸入，文檔是個階段銜接的惟一信息。因此不少開發人員好象是在開發文檔，而不是開發軟件，由於要到開發的後期才能夠看到軟件的「模樣」。

二、沒有迭代與反饋。瀑布模型對反饋沒有涉及，因此對變化的客戶需求很是不容易適應。瀑布就意味着沒有回頭路。

三、管理人員喜歡瀑布模型的緣由是把文檔理解爲開發的速度，能夠方便地界定不一樣階段的里程碑。

 

敏捷開發

極限編程的思想體現了適應客戶需求的快速變化，激發開發者的熱情，也是目前敏捷開發思惟的重要支持者。

敏捷軟件開發是一個開發軟件的管理新模式，用來替代以文件驅動開發的瀑布開發模式。

 

敏捷開發集成了新型開發模式的共同特色，它重點強調：

1.敏捷就是「快」。快才能夠適應目前社會的快節奏，要快就要發揮我的的個性思惟多一些個性思惟的增多。

2.客戶參與。以人爲本，客戶是軟件的使用者，是業務理解的專家，沒有客戶的參與，開發者很難理解客戶的真實需求。

3.強調軟件開發的產品是軟件，而不是文檔。文檔是爲軟件開發服務的，而不是開發的主體。

4.設計周密是爲了最終軟件的質量，但不代表設計比實現更重要。

5.迭代。軟件的功能是客戶的需求，界面的操做是客戶的「感受」。對迭代的強調是縮短了軟件版本的週期。

6.小版本。快速功能的展示，看似簡單，但對於複雜的客戶需求合理地分割與整體上的統一，要很好地兩者兼顧是不容易的。

迭代開發，敏捷開發，區別【一種生命週期模型，項目管理方法集合】

---

        迭代開發是 一種軟件開發的 生命週期模型,與其對應的還有瀑布模型、螺旋模型等等

        敏捷開發是 多種軟件開發 項目管理方法的集合,其中 包括了XP、Scrum等十幾種開發模式,這些開發方法有些共同點,好比重視響應變動,重視實現客戶的價值,重視開發人員的自身發展等等,其核心體如今他們著名的四句原則中.這些開發方法基本都傾向於採用迭代的軟件開發生命週期模型.

        簡單來講, 迭代模型是敏捷開發廣泛使用的軟件生命週期模型, 敏捷開發所包含的內容比迭代模型寬泛的多.

 

敏捷開發中，XP與SCRUM的區別

---

區別之一：  迭代長度的不一樣

XP的一個Sprint的迭代長度大體爲1~2周, 而Scrum的迭代長度通常爲 2~ 4周.

區別之二: 在迭代中, 是否容許修改需求

XP在一個迭代中，若是一個User Story(用戶素材, 也就是一個需求)尚未實現， 則能夠考慮用另外的需求將其替換， 替換的原則是需求實現的時間量是相等的。 而Scrum是不容許這樣作的，一旦迭代開工會完畢, 任何需求都不容許添加進來，並有Scrum Master嚴格把關，不容許開發團隊收到干擾

區別之三: 在迭代中，User Story是否嚴格按照優先級別來實現

XP是務必要遵照優先級別的。 但Scrum在這點作得很靈活， 能夠不按照優先級別來作，Scrum這樣處理的理由是： 若是優先問題的解決者，因爲其它事情耽擱，不能認領任務，那麼整個進度就耽誤了。 另一個緣由是，若是按優先級排序的User Story #6和#10，雖然#6優先級高，可是若是#6的實現要依賴於#10，則不得不優先作#10.

區別之四:軟件的實施過程當中，是否採用嚴格的工程方法，保證進度或者質量

Scrum沒有對軟件的整個實施過程開出養個工程實踐的處方。要求開發者自覺保證，但XP對整個流程方法定義很是嚴格，規定須要採用TDD, 自動測試， 結對編程，簡單設計，重構等約束團隊的行爲。所以，原做者認爲， 這點上，XP的作法值得認同的，可是卻把敏捷帶入了一個讓人困惑的矛盾, 由於xp的理念，結合敏捷模式，表達給團隊的信息是「你是一個徹底自我管理的組織， 但你必需要實現TDD, 結對編程, ...等等」

 

不難發現，這四個區別顯見的是： Scrum很是突出Self-Orgnization, XP注重強有力的工程實踐約束

做者建議， 在管理模式上啓用Scrum， 而在實踐中，創造一個適合本身項目組的XP(「start with Scrum and then invent your own version of XP.」)

 

SCRUM介紹

---

        回顧一下我所認識的scrum，算是對本身知識的一個梳理。
        scrum究竟是什麼，書中都說，它不是方法學，不是過程，而是一個框架。我並無太理解這句話，因此先把scrum中都有些什麼來講一下。

 

        時間：scrum把時間分紅一個個的sprint，也就是迭代週期。這個週期以2-6個星期爲宜，但目前使用的最多的，是一個月，即四個星期。

        每個sprint的開始和結束都會有一個會議，叫作sprint計劃和sprint演示，這很好理解，計劃時計劃作什麼，演示時演示作完的東西。而後，並非演示完了就完事的，sprint還有一個回顧會議，用來對這個sprint進行回顧，哪些作的好，哪些作的很差。這就是改進。

        組成sprint的天天中，都會有每日例會，叫作每日站會，因此謂站會，便是時間很是短的會議，衆所周知的，沒完沒了的會議老是讓咱們，厭倦不已。而這種站會，我想差很少是從這方面來考慮的。

 

        人物：scrum中有scrum master, product owner和scrum團隊。我理解scrum master就是project manager，而product owner就是product manager，團隊仍是那個團隊，只是這裏的團隊，在規模上有必定的限制，它要求人員不要太多，不要太少，3-12個，一般4人團隊比較多見，固然這個具體還得看實際狀況來定。團隊中開發測試人員比是1：1，即pair work。

 

        scrum中的需求，採用story的形式進行描述，整個產品的需求，被列成product backlog，而每個迭代週期要作什麼，是在每一個sprint的計劃會議上進行挑選的，根據po對backlog標記的優先級，團隊對其進行estimate並挑選出這個sprint裏能完成的story，scrum master把它們列入計劃中。

        backlog有一個用於統計的東西，叫作燃盡圖。從字面理解，就是燃燒掉多少的圖，即sprint backlog中的被完成了多少，每完成一個story，就燃燒掉一個story。產品backlog有產品燃盡圖，sprint有sprint燃盡圖。

 

        以上基本就是我瞭解的一些scrum知識點，其中忽略了工具部分和工做開展方式部分。由於採用什麼工具或採用什麼方式來實現，我認爲是根據實際狀況來定的，並且，在每一個sprint回顧會議中，這些東西都會被改進。使用excel或白板來記錄story或backlog並不重要，重要的是，你是否有story或backlog。

 

        所謂框架，是否是就是一種模式？真的很想理解這裏的這個詞。有知道的，請賜教。