常講到的開發模式包括：瀑布式開發、敏捷開發、極限程式設計等。傳統開發模式都是瀑布式開發，按部就班一步步達成目標，但網際網路產品節奏緊湊、業務需求多變，瀑布式開發顯得太笨重，於是出現了極限程式設計、敏捷開發等應對。
瀑布式開發是最典型的預見性的方法，嚴格遵循預先計畫的需求、分析、設計、編碼、測試的步驟順序進行。
瀑布式的主要的問題是它的嚴格分級導致的自由度降低，專案早期即作出承諾導致對後期需求的變化難以調整，代價高昂。瀑布式方法在需求不明並且在專案進行過程中可能變化的情況下基本是不可行的。
敏捷開發以使用者的需求進化為核心，採用迭代、循序漸進的方法進行軟體開發。其中一些原則是從xp中借鑑而來的，實際上敏捷開發的出現一定程度上就是xp和類似的開發思路綜合而來。
敏捷開發核心原則：
1、最重要的是通過盡早和不斷交付有價值的軟體滿足客戶需要。
2、我們歡迎需求的變化，即使在開發後期。敏捷過程能夠駕馭變化，保持客戶的競爭優勢。
3、經常交付可以工作的軟體，從幾星期到幾個月，時間尺度越短越好。
4、業務人員和開發者應該在整個專案過程中始終朝夕在一起工作。
5、圍繞鬥志高昂的人進行軟體開發，給開發者提供適宜的環境，滿足他們的需要，並相信他們能夠完成任務。
6、在開發小組中最有效率也最有效果的資訊傳達方式是面對面的交談。
7、可以工作的軟體是進度的主要度量標準。
8、對卓越技術與良好設計的不斷追求將有助於提高敏捷性。
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的產品需求中；
xp是一種近螺旋式的開發方法，它將複雜的開發過程分解為乙個個相對比較簡單的小週期；通過積極的交流、反饋以及其它一系列的方法，開發人員和客戶可以非常清楚開發進度、變化、待解決的問題和潛在的困難等，並根據實際情況及時地調整開發過程。
xp的基礎和價值觀是交流、樸素、反饋和勇氣；即，任何乙個軟體專案都可以從四個方面入手進行改善：加強交流；從簡單做起；尋求反饋；勇於實事求是。
xp的乙個成功因素是重視客戶的反饋——開發的目的就是為了滿足客戶的需要。
專案執行一般包括如下步驟：需求收集整理、需求方案評審、制定技術方案、技術方案評審、技術開發、聯調測試、發布上線、線上觀察。各種流派的開發模式只是在上述步驟中強調各自的重點，對專案產出做了方向性的規劃，在人力成本、溝通成本、開發成本甚至硬體成本上做協調。
以下根據實際專案經驗，做一些不全面的總結。
1、需求整理和需求方案評審
需求整理一般是產品經理（業務專家）獨自完成的工作，其產出就是需求方案。這一過程往往不被專案組重視，且很難制定量化的指標，因此需求方案往往是作為結論性的文件丟擲，至於其中有多少問題，強依賴於需求方案評審那一兩個小時的評估。
個人認為需求整理應該採取多次的、小範圍溝通的方式，逐步細化和達成方案，並將一些細節方案的選擇形成基本的結論，而不是將這些工作方案需求方案評審會議上。這樣才能將團隊的力量集中打在業務痛點上。
需求方案評審不應只是評估技術實現成本，這個是技術方案評審的重點，需求方案評審更應集中在抓住業務實質，剖析領域模型。
2、制定技術方案和技術方案評審
首先強調一下，單測應該是技術方案的重要一部分。極限程式設計要求先單測後**實現，強調單測實際上就是強調結果，從結果倒推。這種方式有個問題就是單測一開始很難評估全，且評估成本很高。但思路是值得借鑑的，因為單測的評估可以激發專案成員思考方案完備性和邊界條件，這些是很可能導致技術方案調整的，因此單測評審值得一做，但不必先實現單測，這樣成本過高。
技術方案評審與需求方案同理，都應該是在評審前充分溝通，評審更多地是模型評估和全面同步。
技術方案必須考慮資料遷移、灰度方案和詳實可行的驗證方案。
3、技術開發和聯調測試
技術開發最大的風險是進度風險，往往由於方案評估不充分和，每日站會可以規避這一風險，但這只是在溝通層面而不是解決問題層面。盡量在方案制定階段規避這一問題，但如果已經出現，及時溝通和額外成本投入是必要的。
聯調可能是分階段分模組的，因此聯調時間點需要在技術方案評審時就要給出，如果有調整必須及時同步。聯調需要做哪些準備工作也需要在方案評審**定好，以節省聯調成本，否則很有可能會導致聯調延期。
4、發布上線和線上觀察
發布上線很多時候不只會影響單個應用，多應用協調部署需要考慮發布順序，考慮已有業務流量和新業務流量的相容問題。在需要做資料清洗和資料遷移的情況，需要列出精細的執行方案。
Java web開發學習
使用eclipse開發web 持續更新中。一 開發環境 作業系統 windows7 64位 開發工具 eclipse 4.4.0 伺服器 tomcat 8.0 二 遇到問題 1.修改檔案後，啟動serversr失敗。解決方法 修改engine中的defaulthost的localhost為你的網域名...
JavaWeb開發總結
頁面開發總結 一 布局 根據同乙個頁面不同區域的功能不同，劃分為多個區域 1.頁面區域有多少，就可以有多少塊針對性的 區 2.頁面不同區域之間連線的唯一標識可以定義為全域性變數 3.公共類可以抽象為乙個js 4.對應的後台 也可以劃分為多個不同的 區 5.後台 可以按照表劃分區域或者按照功能劃分區域...
WPF Multi Touch 開發 高效開發模式
在beh iors 選單中可以找到fluidmovebeh ior和 translatezoomrotatebeh ior 兩個選項，並將其拖入rectangle 中使矩形具有觸屏操作特性。選擇translatezoomrotatebeh ior 可以進行相關設定，勾選constraintopare...