瀑布式開發、迭代開發，區別【都屬於，生命週期模型】
兩者都是一種開發模式，就像設計模式一樣，考慮的角度不一樣，個人感覺談不到取代一說。
傳統的瀑布式開發，也就是從需求到設計，從設計到編碼，從編碼到測試，從測試到提交大概這樣的流程，要求每一個開發階段都要做到最好。特別是前期階段，設計的越完美，提交後的成本損失就越少。我現在從事的外包項目就是這樣的流程。
迭代式開發，不要求每一個階段的任務做的都是最完美的，而是明明知道還有很多不足的地方，卻偏偏不去完善它，而是把主要功能先搭建起來爲目的，以最短的時間，最少的損失先完成一個“不完美的成果物”直至提交。然後再通過客戶或用戶的反饋信息，在這個“不完美的成果物”上逐步進行完善。
這兩種開發模式都各自具有自己的特點，迭代式開發適合在一些需求信息不明確的項目中，這樣在開發過程中遇到需求的變化時，所帶來的影響要比瀑布式開發小。而現在的很多項目中，需求在項目進行中變化的事兒經常見，所以顯得迭代式開發的優勢更明顯一些。
但是，從本質上來說，二者都不過是一種開發的模式，即使是迭代式開發，在每一個迭代的環節中，不也是此從需求到設計，從設計到編碼，從編碼到測試嗎？這不也是瀑布式模型的體現嗎？只不過這個瀑布式中的每一個階段不需要做到最優化，都留一些任務到下一層迭代中去做而已。
所以，我覺得面對不同的問題採用不同的模式，模式是爲了方便我們開發而服務的，不是要求我們必須按照某一種模式從頭走到尾。
就象迭代式開發，我們其實也經常用到這種模式。比如說開發項目中的某一個模塊。我們先把能夠實現主要功能的代碼寫出來。比如一個查詢模塊，先從模塊的構思到設計再到編碼，先查詢功能的代碼，測試一遍查詢成功。這算是完成了第一層迭代。然後我們要再考慮一層迭代中的一些還未完成的細節問題，比如查詢的check，查詢結果的顯示以及查詢算法的優化等等，這就是第二層迭代。
瀑布式開發，敏捷開發，區別【一種生命週期模型，項目管理方法集合】
瀑布模型的特點（傳統的開發方式）
1、強調文檔
前一個階段的輸出就是下一個階段的輸入，文檔是個階段銜接的唯一信息。所以很多開發人員好象是在開發文檔，而不是開發軟件，因爲要到開發的後期纔可以看到軟件的“模樣”。
2、沒有迭代與反饋。瀑布模型對反饋沒有涉及，所以對變化的客戶需求非常不容易適應。瀑布就意味着沒有回頭路。
3、管理人員喜歡瀑布模型的原因是把文檔理解爲開發的速度，可以方便地界定不同階段的里程碑。
敏捷開發
極限編程的思想體現了適應客戶需求的快速變化，激發開發者的熱情，也是目前敏捷開發思維的重要支持者。
敏捷軟件開發是一個開發軟件的管理新模式，用來替代以文件驅動開發的瀑布開發模式。
敏捷開發集成了新型開發模式的共同特點，它重點強調：
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。