在去年12月底開始接觸高校平臺專案，到現在也快有小半年了。這次的開發不同以往。是以敏捷開發作為開發方式。以前都是遵循傳統的瀑布模型，而新方式的開發思路直接與傳統的開發思路來了個正面碰撞，擦出了陣陣“火花”。

    在一開始接觸敏捷開發時，有些興奮，有些期許，但是在真正用來做專案時，由於瀑布模式已經根深蒂固，再加上對需求不熟悉，對開發環境不熟悉，新方式的開發反而讓人感到彆扭，麻煩，甚至抵觸。

    由於對敏捷開發的不理解，大家也爆發了很多爭論，不過也正是這些爭論，引導我們逐步走向了敏捷開發的正途上。

    記得當初在做yh收銀系統的時候，採用的是傳統的瀑布開發模式。自己做需求也是很費力氣的，首先整理當前版本的系統功能，

設計花費的時間就更多了，我們採用的是三層架構+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更專業，也更方便。