在去年12月底開始接觸高校平台專案，到現在也快有小半年了。這次的開發不同以往。是以敏捷開發作為開發方式。以前都是遵循傳統的瀑布模型，而新方式的開發思路直接與傳統的開發思路來了個正面碰撞，擦出了陣陣「火花」。
在一開始接觸敏捷開發時，有些興奮，有些期許，但是在真正用來做專案時，由於瀑布模式已經根深蒂固，再加上對需求不熟悉，對開發環境不熟悉，
新方式的開發反而讓人感到彆扭，麻煩，甚至牴觸。
由於對敏捷開發的不理解，大家也爆發了很多爭論，不過也正是這些爭論，引導我們逐步走向了敏捷開發的正途上。
記得當初在做yh收銀系統的時候，採用的是傳統的瀑布開發模式。自己做需求也是很費力氣的，首先整理當前版本的系統功能，
收集和整理以往的維護記錄，整理客戶的建議。然後再加上自己維護過程中發現需要改進的地兒
和參考同類軟體
，歷時1周，需求算是基本做出來了，但是還是有很多問題，許多想要的動能，自己也不確定到底是什麼樣的。以至於到概要設計完成後，發現設計與最終想要的差距太大，最終決定推倒重來，又花費了1周的事件才搞定需求。加上前面浪費的時間，光是做需求，就花費了近乙個月的時間了。也就是說這近乙個月的時間，小組成員大部分的時間
（專案方面的）
都荒廢掉了的。
設計花費的時間就更多了，我們採用的是三層架構+2層介面+抽象工廠模式，實現差不多都是組長去設計，然後畫出時序圖來，再安排小組成員去完成。做的過程中發現當初設計有問題，還得推到重新去設計。結果就造成了
**沒花太長時間，而反覆修改設計和各種文件花費時間太多了。
實現過程看著時序圖也不一定可以搞定，而且大家當時的水平也的確有待提高，經常被問題卡住，開發停滯了。沒有乙個例子做參考，做起來也很費勁。甚至有時候為了完成功能，使用簡單的但是不安全的方式實現了，以至於後來得反覆修改。
而且開發時間跨度有點大（最終耗時5個月），小組中有牴觸情緒蔓延。。。
當然我這裡只是說在使用瀑布模式做yh系統時，所遇到的問題，並不是說我們開發的一無是處。相反我們開發突破了以前許多設計枷鎖，讓我們的系統變得很人性化，當然這不是本次討論的重點，就不在這裡說了。
以上這些問題是有部分是能力所限，但是通過改變開發模式也能解決這些問題。而敏捷開發就是其中一種解決方案。
本次在做高校平台專案時，採用的是scrum敏捷開發模式，在簡單了解了敏捷開發模式後，越發感覺敏捷開發的優勢了。瀑布模式是以文件驅動的，而scrum則是以人為核心，只完成必要的文件即可
，它更強調人與人的交流
。而且scrum之所以成為敏捷開發，主要還是因為它能快速響應變化，快速迭代。
按照scrum的開發流程，建立backlog，列story，在迭代計畫會上大家一起評story優先順序（跟scrum稍有不同），然後制定迭代計畫，並一起對本次迭代任務進行評估工時。用集體的智慧型和知識對「做什麼，怎麼做」打成共識。每個人只專注分配給自己或者自己領取的任務模組即可。每日立會也是乙個很不錯的了解開發進度的方式。每次做完任務後，都要叫scrum master來檢查一遍。而且在迭代中期和末期都有集體審查，在很大程度中減少了系統bug，不至於最後bug遍地，無法整合。
當然在這過程中也會遇到問題，被一些難的問題卡住了，會在立會中提到，如果不是很重要的問題，給2天時間解決，否則放棄這個任務，換另乙個人去做。或者採取結對程式設計，這個的確很有效。在對乙個大家都了解都比較少的，或者一些邏輯複雜的問題上，一般採用2種方式。一是2個人同時領取相同的任務，各自做各自的，誰完成了就用誰的。另一種是結對程式設計，2個人坐在一起來完成乙個任務。我更推薦愛你結對程式設計，它在這些問題上的投入往往是1+1>2的，
絕對是乙個very good choice。
本次開發設計到許多陌生的知識，如果單純的理解起來，比較費力，不過如果有工具輔助就是另一回事兒了。本次管理上的不論是「禪道
」還是「jira
」都是非常值得推薦的專案管理軟體。也是通過這兩款專案管理軟體，才使得我能快速了解和熟悉敏捷開發流程。另乙個我覺的非常值得推薦的則是confluence。confluence則是乙個很不錯的wiki，自我感覺要比使用svn更專業，也更方便。
當然並不是所有的專案都適合用敏捷開發來做，選擇哪種開發模式是根據專案而定的。對時效要求比較高的比如網際網路產品，比較適合用敏捷開發。而一些大型、超大型的專案如軍工、航天的，就不太適合敏捷開發。還是那句話，適合的才是最好的。
敏捷 瀑布模型
敏捷模型 核心是快速迭代，擁抱變化。以使用者的需求進化為核心，採用迭代 循序漸進的方法進行軟體開發。因為最終目標是讓客戶滿意，所以能夠主動接受需求變更，這就使設計出來的軟體有靈活性，可擴充套件性。宣言 個體和互動 勝過 過程和工具 可以工作的軟體 勝過 面面俱到的文件 客戶合作 勝過 合同談判 響應...
瀑布模型 迭代模型和敏捷開發
瀑布模型 瀑布模型核心思想是按工序將問題化簡，將功能的實現與設計分開，便於分工協作，即採用結構化的分析與設計方法將邏輯實現與物理實現分開。將軟體生命週期劃分為制定計畫 需求分析 軟體設計 程式編寫 軟體測試和執行維護等六個基本活動，並且規定了它們自上而下 相互銜接的固定次序，如同瀑布流水，逐級下落。...
瀑布模型開發與敏捷開發的對比
瀑布模型開發 嚴格把軟體專案的開發分隔成各個開發階段 需求分析，要件定義，基本設計，詳細設計，編碼，單體測試，結合測試，系統測試等。使用里程碑的方式，嚴格定義了各開發階段的輸入和輸出。如果達不到要求的輸出，下一階段的工作就不展開。強調文件，在開發的後期才會看到軟體的模樣。在這種情況下，文件的重要性彷...